Implementing Single Sign-On using claims

In a federation scenario, claims-based identity providers complying with the WS-Trust/WS-Federation security specification can act on behalf of the users to authenticate against third-party service providers that have a trust relationship established with the IP via some form of metadata exchange. This reduces the burden on the user to log in multiple times and facilitates a seamless Single Sign-On experience. This recipe shows how claims-based security can be used to create an SSO experience within and across the security boundaries easily.

Note

In the world of federation, web SSO is often described as passive, because the token processing must be performed within the limitations of the HTTP protocol, using GET, POST, and so on.

How to do it...

To create a Single Sign-On experience with the RP web application, perform the following steps:

  1. In the requestor web page, create a form body with the SAML token, and use JavaScript to auto-post the form to the RP SSO URL:
    HTTP/1.1 200 OK ...
<html xmlns="https://www.w3.org/1999/xhtml"> <head> <title>Working...</title> </head> <body> <form method="post" action="https://RelyingParty/SsoLogin.aspx">
<p> <input type="hidden" name="wa" value="wsignin1.0" /> <input type="hidden" name="wctx" value="https://Resource.RelyingParty.com"
/>
<input type="hidden" name="wresult" value="&lt;RequestSecurityTokenResponse&gt;...&lt;/RequestSecurityToken Response&gt;" />
<button type="submit">POST</button> <!-- included for requestors that do not support javascript --> </p> </form> <script type="text/javascript"> setTimeout('document.forms[0].submit()', 0); </script> </body> </html>

    Note

    A POST button is also included for the browsers that do not support JavaScript.

  2. Use the SSO page to retrieve the POST token and pass it to the STS for validation:
    POST https://RelyingParty/SsoLogin.aspx HTTP/1.1 &crarr; … &crarr; &crarr; wa=wsignin1.0 &crarr; wctx= https://Resource.RelyingParty.com wresult=<RequestSecurityTokenResponse>…</RequestSecurityTokenResponse>
  3. In the STS, validate the token and return the user context.
  4. In the RP application, generate the encrypted cookie using the context information and the token issuer, and save it.
  5. You will be redirected to the requested page:
    HTTP/1.1 302 ... ~/home

How it works...

The wa parameter specifies the action to be performed. For sign-in, it should be set to wsignin1.0 as defined in the WS-Federation Passive Requestor Profile specification. The security token is returned using the wresult parameter. The value must be set to an XML string corresponding to the WS-Trust RequestSecurityTokenResponse element. The following code snippet shows the structure of a sample RequestSecurityTokenResponse XML string: 

<trust:RequestSecurityTokenResponse
xmlns:trust="http://schemas.xmlsoap.org/ws/2005/02/trust">
<trust:Lifetime>
<wsu:Created>…</wsu:Created>
<wsu:Expires>…</wsu:Expires>
</trust:Lifetime>
<wsp:AppliesTo>
<EndpointReference>
<Address>
https://RelyingParty/SecurityTokenService
</Address>
</EndpointReference>
</wsp:AppliesTo>
<Trust:RequestedSecurityToken>
<saml:Assertion
MinorVersion="1"
AssertionID="_839f..." Issuer=" https://IdentityProvider/SecurityTokenService ">
<saml:Conditions
NotBefore="2009-10-22T14:40:07.978Z"
NotOnOrAfter="2009-10-22T00:40:07.978Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>
https://RelyingParty/SecurityTokenService
</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Subject>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Attribute
AttributeName="name"
AttributeNamespace=
"http://.../ws/2005/05/identity/claims">
<saml:AttributeValue>
mary</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature>
<ds:SignedInfo>
...
</ds:SignedInfo>
<ds:SignatureValue>
.....=
</ds:SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>
...
</X509Certificate>
</X509Data>
</KeyInfo>
</ds:Signature>
</saml:Assertion>
</trust:RequestedSecurityToken>
<trust:TokenType>
http://docs.oasis-open.org/wss/
oasis-wss-saml-token-profile-1.1#SAMLV1.1
</trust:TokenType>
<trust:RequestType>
http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
</trust:RequestType>
<trust:KeyType>
http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey
</trust:KeyType>
</trust:RequestSecurityTokenResponse>

The RP generates an encrypted cookie using the token to prevent the subsequent requests to be redirected for token processing. The encrypted cookie will also store each RP address that participates in the sign-in scenario that is retrieved from the wctx parameter.

There's more...

You can have a look at the WS-Federation Passive Requestor Profile article at http://msdn.microsoft.com/en-us/library/bb608217.aspx for more information on web SSO.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.216.47.169