Previous: The SAML20 mechanism, Up: Mechanisms [Contents][Index]
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]