Posts Tagged SP Initiated SSO

SP-Initiated Single Sign On using SAML 2.0–Architecture and a simple implementation

Identity Provider (idP) : Party which authenticates the user
Service Provider(SP/RP) : Party which provide a resource/service to the user. Also called a relying party.

Below are the high level steps and I will expand on them later in this article :-

  1. User tries to access a resource on the SP website
  2. SP saves the requested resource URL, sees there user does not have a session with them. It then sends the user (with a SAMLRequest) back to the idP it trusts to authenticate.
  3. idP checks if the user has a session with them and If not challenges the user to log in.
  4. Upon successful login, idP sends the user to the SP with a SAML assertion.
  5. SP verifies the SAML assertion, creates a session for the user and lets the user access the resource.

[Click on the below image to enlarge]

image

1. User tries to access a resource on the SP website
This step is simple. User access a link on the SP.
GET http://serviceprovider.com/serviceproviderweb/Folder1/Folder2/Folder3/DeeplyPlacedFile.asp?id=1 HTTP/1.1
Typically each SP website page user accesses directly (e.g. DeeplyPlacedFile.asp) would check If user has an existing session (e.g. has the required valid SP auth cookie), It will let us user stay in the page the SSO flow ends here. If the user does not have an active session next steps (starting from 2) ) below will follow.

Typically, SP website have cookie check in each page via shared lib. In the example below Its an ASP include file which can be used in all the ASP pages within the SP website.

Note the line :-
Response.Redirect “https://federationengine.serviceprovider.com/sp/startSSO.ping?partnerIdpId=https://federationengine.identityprovider.com&TargetResource=”&url
The above line indicates there is an PingFederate idP connection (with the name ‘https://federationengine.identityprovider.com’) on the service provider federation engine.
This will create a AuthNRequest (SAMLRequest) and will port to the SSO URL on the idp side.
Also note that the the requested Url is also tagged along with the TargetResource querystring. This will make sure the idP Connection would create a relaystate token and will map the same to the requested URL. (more details on this later)

<%
Dim protocol
Dim domainName
Dim fileName
Dim queryString
Dim url

protocol = “http”
If lcase(request.ServerVariables(“HTTPS”))<> “off” Then
protocol = “https”
End If

domainName= Request.ServerVariables(“SERVER_NAME”)
fileName= Request.ServerVariables(“SCRIPT_NAME”)
queryString= Request.ServerVariables(“QUERY_STRING”)

url = protocol & “://” & domainName & fileName & “?” & queryString

cookieValue = Request.Cookies(“ServiceProviderAuthCookie”)
if len(cookieValue) < 1  Then

Response.Redirect https://federationengine.serviceprovider.com/sp/startSSO.ping?partnerIdpId=https://federationengine.identityprovider.com&TargetResource=”&url

end if

%>
2. SP asks the idP to authenticate the user
If the SP’s federation server determines there is no active session for the user and user is coming for the first time, the federation server constructs an SAML Authentication request also called “SAMLRequest” and sends the base64 version of it to the idP federation server SSO URL.
It also creates an identifier (as a RelayState), saves along with the originally requested URL as a key-value pair. This is done so that when the idP comes with the same identifier, It can retrieve the originally requested URL and can just redirect the user. This way, there is no need of passing the URL around.

If the authentication request is sent via POST, there are the SAMLRequest and RelayState are sent in hidden fields,
SAMLRequest: PHNhbWxwOkF1dGhuUmVxdWVzdCBWZXJzaW9uPSIyLjAiIElEPSJXcWhtdmZVUDQwOXl6
Sm10cGxDbjdSUkVOX3oiIElzc3VlSW5zdGFudD0iMjAxNi0wMy0wNFQwMTowNjoyNy44MDhaIiB4bWxuczpzY
W1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIj48c2FtbDpJc3N1ZXIgeG1sbnM6c2Ft
bD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+c2FtbDIwLmxwbC5jb208L3NhbWw6SXN
zdWVyPjxzYW1scDpOYW1lSURQb2xpY3kgQWxsb3dDcmVhdGU9InRydWUiLz48L3NhbWxwOkF1dGhuUmVxdWVzdD4=
RelayState: FMCbXM9vrgFI0jT5ZvqC4hieR3JVT4

Below is the Xml representation of the SAMLRequest :-
<samlp:AuthnRequest Version=”2.0″
ID=”WqhmvfUP409yzJmtplCn7RREN_z”
IssueInstant=”2016-03-04T01:06:27.808Z”
xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”>
<saml:Issuer xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”>http://www.serviceprovider.com</saml:Issuer>
<samlp:NameIDPolicy AllowCreate=”true” />
</samlp:AuthnRequest>

Notice the highlighted issuer id. This is the entityid of the service provider. This is needed by the identity provider to determine which party It needs to issue the SAMLResponse to.

3. idP checks if the user has a session with them and If not challenges the user to log in
idP Federation server, upon getting the authentication request, initializes the appropriate connection configuration for the service provider (identified by the SP issuer id sent in the previous step). The configured authentication adapter in teh connection is invoked and user is challenged.

4. idP sends SAML assertion to the SP Federation engine
Upon successful user login, the server issues the SAMLResponse. This SAMLResponse is signed with the idP’s private certificate and other attributes needed for the SP to create the session for the user.
If the authentication request is sent via POST, there are the SAMLRequest and RelayState are sent in hidden fields. Notice, Its the RelayState hidden field has the same value SP passed to the idp in step 2).
SAMLResponse: PHNhbWxwOlJlc3BvbnNlIFZlcnNpb249IjIuMCIgSUQ9IldJcHlvTnVrRkdZQ3Q3b0FuQ1JnOHpFUG9V
QiIgSXNzdWVJbnN0YW50PSIyMDE2LTAzLTA0VDAxOjA2OjE2LjczOFoiIEluUmVzcG9uc2VUbz0iV3FobXZ
mVVA0MDl5ekptdHBsQ243UlJFTl96IiB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6M
RelayState: FMCbXM9vrgFI0jT5ZvqC4hieR3JVT4

XML respresentation of SAMLResponse below :-
Key points here are :-
a) The issuer id “www.identityprovider.com” is the identity provider’s entity id.
b) The SAML is issued to the entity id “www.serviceprovider.com” of the service provider.
c) SAML is posted to the Assertion Consumer Service (ACS) URL https://www.serviceprovider.com/sp/ACS.saml2 of the service provider.
<samlp:Response Version=”2.0″
ID=”WIpyoNukFGYCt7oAnCRg8zEPoUB”
IssueInstant=”2016-03-04T01:06:16.738Z”
InResponseTo=”WqhmvfUP409yzJmtplCn7RREN_z”
xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”
>
<saml:Issuer xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”>www.identityprovider.com</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success” />
</samlp:Status>
<saml:Assertion ID=”fciE1SgZ2WX-duiqbwBiuvZj9XT”
IssueInstant=”2016-03-04T01:06:17.050Z”
Version=”2.0″
xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”
>
<saml:Issuer>www.identityprovider.com</saml:Issuer>
<ds:Signature xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”&gt;
<ds:SignatureValue>
SM2NhtM3jExOy/RDnCMWc/RKnOfsOs2nr3o9JQMjgdT/g16mcxEA6c+1jRPl8imlhNFk48t6obmN
</ds:SignatureValue>
</ds:Signature>
<saml:Subject>
<saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”>48DEDA35890E4746A134920E70844E6A</saml:NameID>
<saml:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”>
<saml:SubjectConfirmationData Recipient=”https://www.serviceprovider.com/sp/ACS.saml2&#8243;
NotOnOrAfter=”2016-03-04T01:11:17.050Z”
InResponseTo=”WqhmvfUP409yzJmtplCn7RREN_z”
/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore=”2016-03-04T01:01:17.050Z”
NotOnOrAfter=”2016-03-04T01:11:17.050Z”
>
<saml:AudienceRestriction>
<saml:Audience>www.serviceprovider.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement SessionIndex=”fciE1SgZ2WX-duiqbwBiuvZj9XT”
AuthnInstant=”2016-03-04T01:06:17.050Z”
>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

5. SP federation engine validates the SAML assertion and redirects to SP portal
SP federation engine verifies the signature on the SAML with the publice cert (previously sent offline) and if the verification is successful, creates the session (e.g. via a cookie).
The RelayState token also comes as part of the POST request. It also pulls up the originally requested URL mapped with that token and redirects the user to the the URL.

, ,

Leave a comment

Random Thoughts

The World as I see it

Simple Programmer

Making The Complex Simple

Ionic Solutions

Random thoughts on software construction, design patterns and optimization.

Long (Way) Off

A tragic's view from the cricket hinterlands