Next: , Previous: , Up: Mechanisms   [Contents][Index]


5.10 The GSSAPI mechanism

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]