This document is work in progress as it is missing information related to wildfly-security API.

Note: This article is not a guide. It is research notes collection for further use in WildFly Security development.

The RFC describing this subject is http://tools.ietf.org/html/rfc6595.

Primary use case for implementing this mechanism is sort of browser profile support in remote authentication to WildFly server namely for  EJB remote client.

Secondary use case is to provide SAML ticket obtained elsewhere and use it as credential to finish authentication process.

SAML version supported will be 2.0 and higher. We intend to use project PicketLink for implementing SAML part of the problem.

Authentication flow picture according to RFC 6595.

            SASL Serv.      Client          IdP
               |>-----(1)----->|              | Advertisement
               |               |              |
               |<-----(2)-----<|              | Initiation
               |               |              | 
               |>-----(3)----->|              | Authentication Request
               |               |              |
               |<-----(4)-----<|              | Response of "="
               |               |              |
               |               |<- -(5,6) - ->| Client<>IdP Authentication
               |               |              |
               |<- - - - - - - - - - -(7)- - -| Authentication Statement
               |               |              |
               |>-----(8)----->|              | SASL Completion with Status
               |               |              |
           ----- = SASL
           - - - = HTTP or HTTPS (external to SASL)
 

1. The SASL server (RP) advertises support for the SASL SAML20 mechanism to the client.
2. The client initiates a SASL authentication with SAML20 and sends a domain name that allows the SASL server to determine the appropriate IdP.
3. The SASL server transmits an authentication request encoded using a Uniform Resource Identifier (URI) as described in RFC 3986 [RFC3986] and an HTTP redirect to the IdP corresponding to the domain.
4. The SASL client now sends a response consisting of "=". Authentication continues via the normal SAML flow, and the SASL server will receive the answer to the challenge out of band from the SASL conversation.
5. At this point, the SASL client MUST construct a URL containing the content received in the previous message from the SASL server.  This URL is transmitted to the IdP either by the SASL client application or an appropriate handler, such as a browser.
6. Next, the user authenticates to the IdP.  The manner in which the end user is authenticated to the IdP, and any policies surrounding such authentication, are out of scope for SAML and  hence for this document. This step happens out of band from SASL.
7. The IdP will convey information about the success or failure of the authentication back to the SASL server (RP) in the form of an authentication statement or failure, using an indirect response via the client browser or the handler (and with an external browser, client control should be passed back to the SASL client).  This step happens out of band from SASL.
8. The SASL server sends an appropriate SASL response to the client.