SAML SSO Profiles

what are SAML profiles????????………… I am so sure that you will get confused, if you hear this word for the first time. As I did ;-) .

SAML Profiles addresses how the set assertions,protocols and bindings can be used in solving a specific use cases. Among such profiles the SSO(Single Sign On) profile plays a major role. :-) Web Browser Based SSO Profile and Enhanced Client or Proxy Profile(ECP) Profile can be considered as major SAML SSO profiles.

I hope some of you may wonder what SSO means tooo. ;-) . To have a quick glance of it , Let’s think of an instance that we use Google and its services.Once we are logged to the Google with our Gmail credentials, and we need to access Google Spread sheet , Google Photos, Calendar, Drive or any other application, we need not to give our credentials again and login. We are redirected to the specific services without being asked to authenticate ourselves again. Wooow !!! It looks Great …..This is simply the SSO. The below diagram shows how this can be achieved via steps described in the SAML SSO profile.

Web Browser Based SSO Profile

How web Browser Based SSO Works?

1. When the User tries to access a secured resource at the Service Provider(SP), the User Agent(eg. browser) sends a HTTP request to the SP asking for the specific resource.
2. Once the request is received by the SP it determines, which Identity Provider(IDP) to be used for authentication. The SAML profile doesn’t forcefully mention about which method to be used but SP may use SAML Identity Provider Discovery Profile.
3. Once the IDP is selected the SP sends an Authentication Request <AuthnRequest> to the IDP via the user agent with the use of either HTTP Redirect, HTTP POST or HTTP artifact binding.
4. The the User is identified by the the IDP. The method used in identification is not specifically mentioned in the profile. If the same user has already logged once, the IDP may use an existing session. If the IDP recieves an authentication request from a new user it establishes a new session.
5. The IDP sends a <Response> to the SP via the user agent, containing an error or Authentication Assertion if the user is valid. The Assertions of a valid user is sent to the Assertion Consumer URL of the SP.
6. Based on the Response from the IDP, the user is granted the access to the resource or denied.

As you see, in the above SSO, the web browser plays a major role when passing the Authentication Requests and Responses. But there are instances where non-browser based clients such as desktop applications also need to SSO. Ooops… Never-mind, in such situations SAML ECP Profile becomes the savior :-p

ECP Profile

As I mentioned earlier, ECP refers to the Enhanced Clients or Proxies. The main difference between the SAML Web based SSO and ECP is that in the previous profile the SP itselfs determines , which IDP to be used in Authenticating the Requests. The SP may use SAML Identiy Provider Discovery Profile in selecting the appropriate IDP to be used. You can have more information on that profile from here. In contrast, ECP , as the name suggests, the client itself chooses the which IDP to be used when accessing a resource from the SP.

How SAML ECP works?

1. When the ECP wants to access a secured resource at the SP , it sends a HTTP request to the SP mentioning that the Request is from an ECP.
2. With the use of SAML Reverse Soap Binding (PAOS) the SP sends an AuthnRequest to the Client .
3. As the Client itself is capable of selecting which IDP to be used, it selects an appropriate IDP to authenticate.
4. Client sends an AuthnRequest to the appropriate IDP using SAML SOAP binding.
5. The IDP identifies the principal. At this stage several messages may be exchanged between the IDP and the client. The details are not mentioned under the SAML ECP profile specification. We can see that this step is very simlilar to the Identification of a user in the SAML web based SSO profile(step 4)
6. Once the IDP identifies the client, it sends an AuthnResponse using SAML SOAP Bindings to the client , targeting the actual receiver , the SP.
7. The Client conveys the AuthnResponse to the SP using PAOS bindings.
8. Based on the response, the SP grants the access to the resource.This step is also similar to the step 6 of web based SSO profile.

I think now you have a clear picture of the two SSO profiles. Great !!!! Hope you are aware that the basic process of identification of the user by the IDP is same in the both processes. I assume you also have the same question that comes into mind at this point :-P . What differs?

The ECP profile is specifically for the non-browser based clients unlike in the web based SSO. In normal SSO the SP chooses which IDP to be used while in the Enhanced clients, the client itself chooses the IDP. In normal SSO, When sending and receiving AuthnRequests and AuthnResponses, by the SP, the messsages pass through the browser. HTTP Redirect, HTTP Post or HTTP Artifact bindings are used to send the requests while HTTP Post,HTTP Artifact bindings are used to receive the responses. Redirect binding is not used in the responses due to fact that the responses will typically exceed the URL length permitted by the most of the browsers.It is because the response may include more information including SAML Assertions.To have more information on the SAML bindings you can refer the document in here. In the Enhanced Clients the AuthnRequest is sent first to the client by the SP using SAML PAOS bindings. Then the client forwards the SAML request to the appropriate IDP using SAML SOAP bindings. When sending the Responses to ECP ,IDP uses SAML SOAP binding and ECP forwards the AuthnResponse to the SP using SAML PAOS binding.

I think now you got my point !!!!! It is the flow of messages that differentiate Web SSO from ECP. And also when communicating with the Enhanced Clients you should understand that the both SP and IDP should support ECP :-0

SSO