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 GS2-KRB5) 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. (For historical reasons, if the GSASL_AUTHZID property is not specified, this mechanism checks for the GSASL_AUTHZID property and if present will use that as the authorization identity – this behaviour will be removed after the year 2012 so you should update your code to use only GSASL_AUTHZID.)

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.

This implementation 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.