When working with SSO with SAML, it is vital that one understands the difference between Identity Provider Initiated Single Sign On and Service Provider Initiated SSO. Before that, it’s important to understand who Identity Providers and Service Providers are and their differences.
Given below are the definitions from the OASIS Organization that created SAML.
“An Identity Provider is a kind of provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles”
“A Service Provider is a role donned by a system entity where the system entity provides services to principals or other system entities”
In the context of this discussion, an Identity Provider is basically an entity that provides authentication for it’s users, whereas the webapp using this service could be called as the Service Provider. In the Travelocity Sample in my previous post, travelocity.com is the SP whereas the WSO2 Identity Server is the IDP.
Now the difference between IDP Initiated SSO and SP Initiated SSO is quite simple. In SP Initiated SSO, the Single Sign On process is initiated by the web application. The user first visits the webapp, then the user is redirected to the IDP along with an AuthnRequest generated at the SP. The Travelocity Sample in my previous post is a classic example of this scenario. When the user visits http://localhost:8080/travelocity.com, and when he clicks on the hyperlink to login with SAML, the webapp initiates the SSO process with an AuthnRequest. A sample of the AuthnRequest sent is given below.
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://localhost:8080/travelocity.com/home.jsp" Destination="https://localhost:9443/samlsso" ForceAuthn="false" ID="0" IsPassive="false" IssueInstant="2016-01-18T12:36:02.365Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" > <samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">concurUSD</samlp:Issuer> <saml2p:NameIDPolicy xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" SPNameQualifier="Issuer" /> <saml2p:RequestedAuthnContext xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact" > <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef> </saml2p:RequestedAuthnContext> </samlp:AuthnRequest>
The AuthnRequest contains important information such as the Assertion Consumer URL, the issuer and the NameID Format which is required by the IDP to identify where to redirect the request. Having authenticated the user, the IDP responds with a SAML Response and the process is similar for both types after this.
On the other hand, when using IDP Initiated SSO, the user does not go through the webapp first, but rather is directed to the IDP. So the first thing the user sees is the authentication page of the IDP. This is done by using a query string along with the URL.
The sample URL with the query string used by the WSO2 IS running on localhost port 9443, is given below.
Here the <sp-issuer> is the Issuer value we define when creating a Service Provider in the WSO2 IS Management Console.
So in the same travelocity example, if I want to use IDP Initiated SSO, the first thing that needs to be done is to “Enable IdP Initiated SSO” in the Service Provider configuration in the WSO2 IS. This is done by selecting the Service Provider “travelocity.com” from the list of SPs, then Inbound Authentication Configuration -> SAML2 Web SSO Configuration. Then click on edit, then check the “Enable IdP Initiated SSO” check-box at the very bottom. The save the configuration.
Now instead of having to go through http://localhost:8080/travelocity.com, and having to click on the SAML 2 hyperlink, the user can directly go to the URL given below and he shall be directed to the WSO2 IS authentication page.
Both these methods are equally used in real life and the choice of one over the other, depends heavily on the requirement of the user.
Hope you enjoyed the post, do drop a comment if I’ve missed anything :)