The SAML20 mechanism makes it possible to use SAML in SASL, in a way that offloads the authentication exchange to an external browser. The protocol implemented is as specified in RFC 6595.
The mechanism makes use of the following properties: GSASL_AUTHZID,
In client mode, the mechanism will retrieve the
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
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
properties when forming the redirect URL. The URL is passed to the
client which will hopefully complete authentication in the browser. The
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 browser
accessing the redirect URL. The server side is expected to call a SAML
library of your choice to generate the AuthRequest and to implement an
AssertionConsumerService 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. It
uses the Lasso SAML implementation (http://lasso.entrouvert.org/).
The example may be used as inspiration for your own server
gsasl command line client supports SAML20 as