This the 2nd part of a 2 part blog series of which we will extend ADFS 2.0 to allow alternative login credentials. If you would like more information of the objectives of this series please refer to part 1.
With your application now successfully integrated we can focus on the objective of uplifting ADFS 2.0 to allow 3rd party STS integration. As part of this series we are utilising Dominick Baier (@leastprivilege) Identity Server which provides us with the extensibility to integrate a with a custom authentication store.
Installing Identity Server
Hopefully by now you will have already configured identity server by following the instructions at http://vimeo.com/51088126, this should leave you with a working understanding of the STS user configuration process. One thing to be mindful when installing IdentityServer and ADFS on the same server is that the federation-metadata addresses are registered to the ADFS proxy service, this means that the request is sent directly to the ADFS windows service.
Due to this you are unlikely to be able to obtain the IdentityServer federation metadata required to create the Trusted claims provider exchange automatically. This makes configuring the Trust a manual process, I would recommend hosting the services on different servers for this reason.
Creating the test account
In order to test the ADFS integration and limit the changes we will create and configure IdentityServer v2 with an out of the box account and configure ADFS as a relying party Trust. To begin this process we need to create a test user account within Identity Server.
Browse to the IdentityServer home page and sign in, click the administration link:
Click Users on the configuration menu.Click New and Provide the test user details, ensuring you add the user to the IdentityServerUsers group (this enables the ability for users to login to the STS).Now the user is added we need to enable the WS-Trust protocol, WS-Trust provides the ability to connect directly to the STS and is an extension of WS-Security. WS-Trust enables us to connect directly via a SOAP channel and request tokens.
To enable WS-Trust click Protocols, select WS-Trust and Save Changes.To validate WS-Trust is enabled, click the home link and select Application Integration. You should now see the addition WS-Trust meta-data and mixed mode security endpoints.Identity Server provides several out of the box claims. These can be viewed at the federation metadata endpoint address above.
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"/>
<auth:ClaimType Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"/>
<auth:ClaimType Uri="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"/>
<auth:ClaimType Uri="http://identityserver.thinktecture.com/claims/profileclaims/twittername" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"/>
<auth:ClaimType Uri="http://identityserver.thinktecture.com/claims/profileclaims/city" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"/>
<auth:ClaimType Uri="http://identityserver.thinktecture.com/claims/profileclaims/homepage" xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"/>
As you can see we have access to standard claims (such as name, emailaddress and role). The final 3 claims are obtained via configuration twittername, city and homepage. The configuration for these can be found in the configuration folder in the profile.config file.
type="System.Web.Providers.DefaultProfileProvider, System.Web.Providers, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
<!-- properties that should get turned into claims go here -->
<add name="City" />
<add name="HomePage" />
<add name="TwitterName" />
User profile settings are added using the profile link on the users configuration page.With the User configured we need to configure ADFS as a relying party. This is achieved via the Relying Parties and Resources Tab. To configure ADFS we will use the federation passive endpoint address (https://<<ADFSDOMAIN>>/adfs/ls).This concludes the configuration of IdentityServer for processing of claims from within ADFS (for now). In order for us to complete our mission, we need to uplift our ADFS installation to accept claims from our new STS.
Before we progress, please ensure you have the ability to access to the federation meta-data from your ADFS STS.
Open up the ADFS MMC and Browse to the Trust Relationships, Claims Provider Trusts. Select Add Claims Provider Trust, this will start the Trust Wizard, click Start. You now have 2 options, import from the Federation Metadata or Browse directly depending on your configuration. Either upload or browse directly to the meta-data address as below:Click Next, Provide a Display Name, Next and Finish. Ensure you open the Edit Claims Rules Dialog at this point.Add a rule which passes the Name through to ADFS from the Trusted Provider. Click Finish.
The last step to configure and allow remote Trusts is to configure ADFS as a valid realm audience, this is achieved via Windows Powershell. Open up the powershell console and run the following script (Replace <<ADFSDOMAIN>> with your ADFS domain.
set-ADFSProperties -AcceptableIdentifier "https://<<ADFSDOMAIN>>/adfs/ls"
We now have a fully configured Trust between ADFS and Identity Server. This trust is pretty useless as we now need to modify FormsSignIn.aspx to establish a login to our 3rd party STS.
Modifying ADFS FormsSignIn.aspx
ADFS 2.0 on Windows Server 2012 utilises .NET 4.5 and therefore WIF baked into the Framework. This is the use-case I am working against in this post. Unfortunately, .NET 4.5 removes the WS Channels which are fundamental to talk to WS-Trust services. Luckily for us Dominick Baier has captured these from the WIF 3.5 source and exposed them in the IdentityServer GitHub source.
This source has been refactored into a component dedicated for the purpose of remote Username and Password STS contact. ADFS Helper (and Source) can be downloaded below.
Gm.Adfs.Helper includes a method which provides the ability to login to the remote STS without overly modifying the FormsSignIn.aspx.cs. The core method in the helper is shown below. Gm.Adfs.Helper.RemoteSignIn.SignIn accepts 7 parameters:
wsTrustAddress = The address of the remote STS (WS-Trust address from application integration).
applicationRealm = The application realm configured in the relying party trust.
username = Authenticating user.
password = Authentication password.
ignoreCertificateErrors = Whether to globally ignore invalid certificates (Non-Trusted publishers).
authenticationCertificateMode = The authentication validation certificate mode.
claims = A parameter array of RequestClaim requests.
public static SecurityToken SignIn(
params RequestClaim claims)
ServicePointManager.ServerCertificateValidationCallback = delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
var binding = new UserNameWSTrustBinding(SecurityMode.TransportWithMessageCredential);
using (var factory = new WSTrustChannelFactory(binding, wsTrustAddress))
factory.TrustVersion = TrustVersion.WSTrust13;
factory.Credentials.UserName.UserName = username;
factory.Credentials.UserName.Password = password;
factory.Credentials.ServiceCertificate.Authentication.CertificateValidationMode = authenticationCertificateMode;
// create token request
var rst = new RequestSecurityToken
KeyType = KeyTypes.Bearer,
RequestType = RequestTypes.Issue,
AppliesTo = new EndpointReference(applicationRealm)
foreach (var claim in claims)
// request token and return
var output = factory.CreateChannel().Issue(rst, out response);
Please ensure you understand the code above before attempting to integrate a 3rd party STS via FormsSignIn.aspx.cs.
With all of the above complete, you are now ready to modify the FormsSignIn.aspx.cs. Modifying the page is simple, just add the required namespace and the required SubmitButton modification. The code below shows the modification to the SubmitButton method. This approach first attempts to login to the remote STS and then falls back to ADFS, enabling both authentication methods to be supported.
Add the following Namespaces to the FormsSignIn.aspx.cs
Modify the SubmitButton with the following code, modifying the OtherSTSAddress and YourSTSAddress variables.
const string OtherSTSAddress = "https://idserv.riddify.co.uk/issue/wstrust/mixed/username";
const string YourSTSAddress = "https://mcad.riddify.co.uk/adfs/ls";
protected void SubmitButton_Click(object sender, EventArgs e)
var token = RemoteSignIn.SignIn(
catch (FaultException fex)
catch (AuthenticationFailedException ex)
//catch (Exception ex)
Please take note of the RequestClaims line of code, this can be modified to enable custom claims to be progressed through ADFS. Below I have modified the code to show a request for twitter account from IdentityServer.
var token = RemoteSignIn.SignIn(
These claims will all need to be configured to pass through to your receiving relying party, so please do not forget!!! This was discussed in part one but needs to be configured using a Relying Party Claim Rule.
Modifying ASP.NET MVC Test Page.
With the above complete we can modify out ASP.NET MVC application to populate the ViewBag with both the Name and Twitter claim.
public ActionResult Index()
ViewBag.Identity = Thread.CurrentPrincipal.Identity;
var claims = Thread.CurrentPrincipal.Identity as System.Security.Claims.ClaimsIdentity;
var twitter = claims.Claims.FirstOrDefault(p => p.Type == "http://identityserver.thinktecture.com/claims/profileclaims/twittername");
ViewBag.Twitter = twitter.Value;
Which outputs the following into the view.
ViewBag.Title = "Index";
Thank you for reading through this series. I hope you have reached an understanding of customising ADFS for custom authentication login.
My next blog post will expose the methods used to customise identity server, replacing IUserRepository and IClaimsRepository.