Integrating with a passive STS.

By | Nov 2, 2015

A passive STS (IP-STS) is a website that issues a token and uses the browser to direct the flow of the application through redirects. The following example will be integrating a website with a passive STS that issues tokens using the WS-Federation standard. Click here if you wish to see how to create your own passive STS.

WS-Federation builds on WS-Trust by allowing several independent web-sites to join together in their trust of a common token. Website A, B & C trusts the same STS and so they can extend this trust so that the client that is logged onto Website A can now access resources on WebSite B & C aswell without having to login to them specifically. Website B & C will obviously have to specifically allow clients from website A access. This is also called SSO or Single Sign On.

Passive STS integration into a website or more accurately called the Relaying Party (RP) can be done by referring to the xml provided at the end of the article.

Add references in your project to System.IdenityModel and System.Identitymodel.services.

SystemIdenityModelReferences

Next add the following configuration sections for the system identityModel.

Next,

  • remove the FormsAuthentication module
  • add the WSFederationAuthenticationModule
  • add the SessionAuthenticationModule

Next

  • Set the Authentication mode to Forms.
  • Set the Authorization for the site. The authorization section will cause all un-authenticated users to be redirected to the passive STS identity provider.

Next Add the system.identityModel block into the web.config. The following section tells the WSFederation module to where it should redirect unauthenticated users and how to determine if a user is authenticated or not.

Wsfederation_config

  • A – AudienceUris, this is a list of websites which is allowed to use or share the token provided by the STS. The client requesting the token needs to say who else is allowed to use the token. This is what people refer to as single sign on. Note that the single sign-on will only be valid with-in the browser session meaning that if you go to the site in another browser a logon will be required again. The sessino token can also not be shared between applications outside of the browser.  If the browser is closed the session will be over. A way to prolong the usage of the token is to persist it too a cookie.

    Single signon (SSO)is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications

  • B – Trusted Issuers – In the trusted issuer section the website specifies the identity of the STS from which it is expecting to receive the token from. If a token is received and the details of the token does not match the issuer registry , the token will be rejected and the request will be redirected to the STS specified in the federation configuration section. This is usually the part of the configuration which is prone to give the most problems. When setting up this section do not copy the thumbprint out of the certificate dialog. Type it by hand as sometimes there are invisible whitespace characters present or the charset being used causes the validation to fail although it visually matches.CertificateDialog
  • C – Certificate validation, as the name of the element suggests in this section you specify how you wish to validate the certificate identity that signed the token.
  • D -Cookie Handler. The token is wrapped in a session cookie within the browser and is received by a cookie handler, because of the size of the token it will be necessary to switch on chunking. Chunking breaks the cookie up into multiple pieces so that all browsers can handle it.
  • E – WS-Federation. The passive redirection of the client is set-up in this section. If a request is received and the user is not authentication, meaning no security token was present or access to the resource was not allowed the request will be redirected to the issuer which is the STS. Note that there are more properties available than the ones explained below.
    • Issuer – This is the url of the STS.
    • Realm – This is the resource that access is being requested for. I am not 100% sure of its use but it tends to be the same as the reply address.
    • Reply – This is the address to which the STS will redirect to once a successful login has bee processed by the STS.

Here is a sample of the sections needed for the  ws federation and system.identitymodel in the configuration XML.


<?xml version="1.0"?>

<!--
For more information on how to configure your ASP.NET application, please visit
http://go.microsoft.com/fwlink/?LinkId=169433
-->

<configuration>

<configSections>
<section name="system.identityModel"
type="System.IdentityModel.Configuration.SystemIdentityModelSection, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<section name="system.identityModel.services"
type="System.IdentityModel.Services.Configuration.SystemIdentityModelServicesSection, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
</configSections>

<system.webServer>

<modules runAllManagedModulesForAllRequests="true">
<remove name="FormsAuthentication" />
<add name="WSFederationAuthenticationModule"
type="System.IdentityModel.Services.WSFederationAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
preCondition="managedHandler" />
<add name="SessionAuthenticationModule"
type="System.IdentityModel.Services.SessionAuthenticationModule, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
preCondition="managedHandler" />
</modules>

</system.webServer>

<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />

<authentication mode="Forms"/>
<authorization>
<deny users="?"/>
<deny users="*"/>
</authorization>
</system.web>

<system.identityModel>
<identityConfiguration>
<audienceUris>
<add value="https://localhost/WebSiteA" />
<add value="https://localhost/WebSiteB/" />
</audienceUris>
<issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<trustedIssuers>
<add thumbprint="4E0018F8E1EEE3BE4C60F1040037A27F2334C966" name="https://localhost/STS/" />
</trustedIssuers>
</issuerNameRegistry>
<certificateValidation certificateValidationMode="PeerOrChainTrust" />
</identityConfiguration>
</system.identityModel>
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="true" mode="Chunked" path="/" />
<wsFederation passiveRedirectEnabled="true" issuer="https://localhost/STS/" realm="https://localhost/WebSiteA/" reply="https://localhost/WebSiteA/" requireHttps="true" />
</federationConfiguration>
</system.identityModel.services>

</configuration>


 

Related

WCF Security Token Service
Troubleshoot WCF Security connectivity
Asp.net security pipeline

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
Notify of