Next: The GS2-KRB5 mechanism, Previous: The SECURID mechanism, Up: Mechanisms [Contents][Index]
The GSSAPI mechanism allows you to authenticate using Kerberos V5. The mechanism was originally designed to allow for any GSS-API mechanism to be used, but problems with the protocol made it unpractical and it is today restricted for use with Kerberos V5. See the GS2 mechanism (see The GS2-KRB5 mechanism) for a general solution. However, GSSAPI continues to be widely used in Kerberos V5 environments.
In the client, the mechanism is enabled only if the user has acquired
credentials (i.e., a ticket granting ticket), and it requires the
GSASL_AUTHZID, GSASL_SERVICE, and GSASL_HOSTNAME
properties. (Earlier versions of the library incorrectly probed for
GSASL_AUTHID and used it as the authorization identity.)
In the server, the mechanism requires the GSASL_SERVICE and
GSASL_HOSTNAME properties, and it will invoke the
GSASL_VALIDATE_GSSAPI callback property in order to validate the
user. The callback may inspect the GSASL_AUTHZID and
GSASL_GSSAPI_DISPLAY_NAME properties to decide whether to
authorize the user. Note that authentication is performed by the
GSS-API library and that GSASL_AUTHID is not used by the server
mechanism, its role is played by GSASL_GSSAPI_DISPLAY_NAME.
The protocol does not distinguish between an absent authorization identity and the empty authorization identity. Earlier versions of the library returned the empty string but currently it returns NULL, it is suggested to treat both the same for this mechanism.
The server-part does not support security layers. You are recommended to use TLS instead.
The GSSAPI mechanism was specified as part of the initial core SASL framework, in RFC 2222, but later revised in RFC 4752 to only apply to Kerberos V5.
Next: The GS2-KRB5 mechanism, Previous: The SECURID mechanism, Up: Mechanisms [Contents][Index]