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


5.13 The OPENID20 mechanism

The OPENID20 mechanism makes it possible to use OpenID in SASL, in a way that offloads the authentication exchange to an external web browser.

The mechanism makes use of the following properties: GSASL_AUTHID (for the OpenID User-Supplied Identifier), GSASL_AUTHZID, GSASL_OPENID20_REDIRECT_URL, GSASL_OPENID20_OUTCOME_DATA, GSASL_OPENID20_AUTHENTICATE_IN_BROWSER, and GSASL_VALIDATE_OPENID20.

In the client, the mechanism is enabled by default. The GSASL_AUTHID property is required and should contain the User-Supplied OpenID Identifier (for example https://josefsson.org). If set, GSASL_AUTHZID will be used by the client. The client will be invoked with the GSASL_OPENID20_AUTHENTICATE_IN_BROWSER callback to perform the OpenID authentication in a web browser. The callback can retrieve the GSASL_OPENID20_REDIRECT_URL property to find out the URL to redirect the user to. After authentication, the client can retrieve the GSASL_OPENID20_OUTCOME_DATA property with the OpenID Simple Registry (SREG) attributes sent by the server (if any).

In the server, the mechanism is enabled by default. The server will request the GSASL_OPENID20_REDIRECT_URL property, and your callback may inspect the GSASL_AUTHID to find the OpenID User-Supplied Identifier. The server callback should perform OpenID discovery and return the URL to redirect the user to. After this, the user would access the URL and proceed with authentication in the browser. The server is invoked with the GSASL_VALIDATE_OPENID20 callback to perform the actual validation of the authentication. Usually the callback will perform some IPC communication with an OpenID consumer running in a web server. The callback should return GSASL_OK on successful authentication and GSASL_AUTHENTICATION_ERROR on authentication errors, or any other error code. If the server received some OpenID Simple Registry (SREG) attributes from the OpenID Identity Provider, it may use the GSASL_OPENID20_OUTCOME_DATA property to send these to the client.

Note that OpenID itself is not implemented by the GNU SASL library. On the client side, no OpenID knowledge is required, it is only required on the server side. The client only needs to be able to start a web browser to access the redirect URL. The server side is expected to use an OpenID library to generate the redirect URL and to implement the Service Provider (SP) to validate the response from the IdP. There is a complete proof-of-concept example with a SMTP server with OpenID 2.0 support distributed with GNU SASL in the examples/openid20/ sub-directory. It uses the JanRain PHP5 OpenID implementation and require a web server to implement the OpenID SP. The example may be used as inspiration for your own server implementation. The gsasl command line client supports OPENID20 as a client.

The OPENID20 mechanism is specified in RFC 6616.


Previous: The SAML20 mechanism, Up: Mechanisms   [Contents][Index]