Another way to deploy the communication channel between lxadm and the sindes server is to use the GSSAPI mechanism. The Generic Security Services API, as the name implies, is not specific to any authenticaion tehnique. GSSAPI is geared toward developers of client/server applications who wish to add strong authenitcation support to their protocols. It provides a generic interface and message format that can encapsulate authentication exchanges from any authentication method that has a GSSAPI-comliant library. GSSAPI insulates aplication programmers from the specific programming interface for particular authentication methods. GSSPIlaso provides a standard message format so that protocols can support many different authenitcaion methods without changing the protocol itself. GSSAPI does not define a protocol, authentication or security mechanism itself. It instead makes it easier for application programmers to support multiple authentication mechanism by by providing a uniform, generic API for security services. Kerberos supports GSSAPI, so any application that supports GSSAPI, also support Kerberos.
A note: while GSSAPI is mostly standardized, there are still some differences between the C language bindings of the available implementations, particularly the MIT and Heimdal implementations of GSSAPI.12.1
Here in CERN GSSAPI is widely used: for example, for the GRID authentication mechanism, for the SSH protocol, for example. A lot of programs use it, for example, Cyrus IMAP, OpenLDAP.
The basic idea is that we've already all the technologies, like Kerberos, and that GSSAPI is indipendent from tha authentication layer used. So, if we want to switch from Kerberos to another one GSSAPI compliant library, we're free to do it. It is well documented and well-known. It's supported by Heimdal Kerberos.
The problem is that I don't know how the GSSAPI server can interact with SINDES. I must investigate on it.
In fact, we can use GSSAPI for the transmission of the data and for the authorization from lxadm to the sindes server.
Quoting from [6]:
As its name implies, the GSS-API enables programmers to write applications that are generic with respect to security; that is, they do not have to tailor their security implementations to any particular platform, security mechanism, type of protection, or transport protocol. Although the GSS-API enables applications control over security aspects, a programmer using GSS-API can write a program that is ignorant of the details of protecting network data. Therefore, a program that takes advantage of GSS-API is more portable as regards network security. More than anything else, this portability is the hallmark of the Generic Security Standard API. The GSS-API does not actually provide security services itself. Rather, it is a framework that provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies such as Kerberos v5 or public key technologies.
We can do mutual authentication (the server must trust the client and viceversa)