In this article series, I am going to address how to create you own custom Security Token Service (STS) to authenticate your users using claims, and using it through ACS to offer more Identity Providers to your Azure app.
This article series is composed of:
- Build you STS as a Web App (and not a Website) ← Your are here!
- Create and configure your certificates in your STS
- Understand the FederationMetadata.xml file
- Use your STS in the cloud through ACS
- Put your web app + your STS in Windows Azure
1. Build your own STS as a Web App (and not a Website)
Today, WIF templates are offering your to build your Security Token Service as a Website.
What we would like to do is to use this “Website” as part of our Azure project, but the issue is Azure SDK only support importing “Wep Application” type of projects…
No problem, let’s just create a Web Application from scratch you will see how simple it is to create a STS from that.
1. Web App creation
First, let’s create a Windows Azure project with one ASP.NET web role.
Once done, let’s have a look to the web.config of our web role; in our case, I just simplified it to only keep MembershipProvider and RoleProvider, both pointing to a SQL Azure Backend.
So, what does this web.config has that make it so special for a STS web app?
Lets have a quick look at what this really simple web role contains:
- MemberShipProvider and RoleProvider providers to configure your identity used in your STS,
- a “Forms” based authentication, redirecting to “Login.aspx” to validate user identity withtin the STS
Now, let’s add a few thing that will make our simple ASP.NET web role a real STS.
2. Adding a couple of pages to the web role
Adding the “Login.aspx” webpage:
This webpage is the one that will be used to authenticate users coming to the STS; most of the work is done just by having providers set as on the web.config. This page just needs to contain a Login ASP.NET control that will automatically use providers. As first call done to the STS will try to reach the PassiveSTS.aspx page, user will be redirected there once successfully authenticated.
You can find here a sample of a template of the Login.aspx page (easy to obtain from VS IDE).
Adding the “PassiveSTS.aspx” webpage:
This page is the one where the magic is done.
On the HTML side, it is an empty page; on the code-behind side, there will be a little bit more code, that will validate consistency of request parameters coming from the Relying Party (these parameters can be found as URL encoded within the ReturnUrl query parameter on the Login.aspx webpage).
Once parameters received from RP are validated, a couple of additional classes will be called to create, sign and encryt the SAML token that will be sent back to ACS (find here the code-behind of my sample PassiveSTS.aspx.cs webpage for reference).
these custom classes are getting called on one line in this webpage:
SecurityTokenService sts = new MembershipSTS(MembershipSTSConfiguration.Current);
Let’s now have a look on how these classes are built.
3. Add specific code for your STS to generate your auth tokens
Code you will find here is just coming from sample classes generated from the WIF STS Website you can generate.
A small addition here: you will need here to fill up details about certificates you web role will use (we will see how certificates are created in my 2nd article on this series).
First file is MembershipSTSConfiguration.cs: this class is used to set the Signing certificate used for your token (adding public key in the FederationMetadata.xml file is to be found in the 3rd part of this series article).
Second file is MembershipSTS.cs: this one will do 3 things:
- Verify if the site requesting a token has the right to do so (through the GetScope overridden method),
- Set the certificate that will be used to encrypt the token (though same method),
- Create and add claims to the claim response according to the used identity against the STS app (through the GetOutputClaimsIdentity overridden method)
Now that your STS is ready code-wise, let’s add certificates to it to sign and encrypt our token… In my next article!