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

5.12 The SAML20 mechanism

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


In client mode, the mechanism will retrieve the GSASL_AUTHZID and GSASL_SAML20_IDP_IDENTIFIER properties and form a request to the server. The server will respond with a redirect URL stored in the GSASL_SAML20_REDIRECT_URL property, which the client can retrieve from the GSASL_SAML20_AUTHENTICATE_IN_BROWSER callback. The intention is that the client launches a browser to the given URL, and then proceeds with authentication. The server responds whether authentication was successful or not.

In server mode, the mechanism will invoke the GSASL_SAML20_REDIRECT_URL callback and the application can inspect the GSASL_AUTHZID and GSASL_SAML20_IDP_IDENTIFIER properties when forming the redirect URL. The URL is passed to the client which will hopefully complete authentication in the browser. The server callback GSASL_VALIDATE_SAML20 should check whether the authentication attempt was successful.

Note that SAML itself is not implemented by the GNU SASL library. On the client side, no SAML knowledge is needed, 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 call a SAML library to generate the AuthRequest and to implement an AssertionConsumerService (ACS) to validate the AuthResponse. There is a complete proof-of-concept example of a SMTP server with SAML 2.0 support distributed with GNU SASL in the examples/saml20/ sub-directory. The example uses the Lasso SAML implementation ( and require a web server for the ACS side. The example may be used as inspiration for your own server implementation. The gsasl command line client supports SAML20 as a client.

The SAML20 mechanism is specified in RFC 6595.

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