With Azure’s Access Control service retiring next month, I needed to find another way to use an on-premise Active Directory account without changing the current login process I already set up. Without using any complex code logic, I leveraged Microsoft’s Single Sign-On (SSO) on my existing ASP.NET MVC web application.
Thanks to Microsoft’s Active Directory Federation Services (AD FS), implementing Single Sign-On (SSO) is now a whole lot easier!
Here is my solution to implement SSO using ASP.NET MVC, AD FS and the On-Premise Active Directory account.
AD FS is an enterprise-level identity and access management service. Because it runs as a separate service, any application that supports WS-Federation and Security Assertion Markup Language (SAML) can leverage this authentication service.
Where to use this solution?
This article shows how to use an on-premise Active Directory account services to securely login a domain user on an external ASP.NET MVC application. This eliminates the need to create and maintain different login credentials for different applications. This solution can also be used in desktop and mobile applications.
Here, I used a preconfigured AD FS Single Sign-On. Before I created the ASP.NET MVC application, I added our URL as a “Relying Party Trust” on the server where the AD FS is configured. If this is running on a client machine, ask a system admin to perform the steps below.
Adding a Relying Party Trust
Log into the server where AD is installed. Open the Server Manager Dashboard. Under Tools choose AD FS Management.
Choose Add Relying Party Trust
Choose the option “Enter data about relying party manually” and click “Next”
Add the display name as “Example Enterprise AD FS” and click Next/
Choose the “AD FS profile “option and click Next.
Under Relying party trust identifier add your application’s website. Click Add and then click Next.
The website needs to have an SSL certificate and https as the navigation path. The AD FS will only communicate through https context. For demo purposes, we have an IIS Express development certificate.
Close the wizard.
In the new popup window, click “Add Rule.”
Choose the Claim rule template as “Send LDAP Attributes as Claims” and click Next.
Add a Claim rule name (my example here is “Example Enterprise Claim”)
Select “Active Directory” as the Attribute Store.
Configure the LDAP attributes to outgoing claim types. Add the above four LDAP attributes and their corresponding outing claim type.
Set your website URL as the destination page. AD FS will need to redirect back after a successful domain account login.
On the AD FS Management window, expand Trust Relationships on the left side.
Click Relying Party Trusts. Right-click on your trust and open Properties.
Under the Endpoints tab, add a WS-Federation Passive Endpoint with your URL.
After a successful login, the data is encrypted by default. I needed a thumbprint of the client’s SSL certificate that is used by AD FS. After receiving the thumbprint, I am now ready to configure the ASP.NET MVC application.
Configure the ASP.NET MVC Application
Open Visual Studio. Choose ASP.NET Web Application. Enter a project name (my example here is AD FS-Demo). Select a folder where you want to create the project.
Click OK. In the next screen, choose MVC as the project. Under Authentication, click Change Authentication and change the Authentication to Individual User Accounts.
Add the “Microsoft.Owin.Security.WsFederation” package. Installing this will also install its dependencies.
Under Solution Explorer, open the file “~/App_Start/Startup.Auth.cs” and add the following code.
The FederationMetadata.xml URL from the AD FS server. Wtrealm is the current website URL (i.e., https://www.example.com/).
The last option Wreply is used to call the DomainLogin method after successfully logging in from the AD FS server.
To read back claims from the server, add these claim identifiers in web.config.
<add key="ClaimsNameIdentifier" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" /> <add key="ClaimsUPNIdentifier" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" /> <add key="ClaimsEmailIdentifier" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
To read data from the encrypted claims, add the following configuration setting in the web.config.
<system.identityModel> <identityConfiguration> <audienceUris> <add value="https://www.example.com/" /> </audienceUris> <issuerNameRegistry type="System.IdentityModel.Tokens.ValidatingIssuerNameRegistry, System.IdentityModel.Tokens.ValidatingIssuerNameRegistry"> <authority name="http://AD FS.server.com/AD FS/services/trust"> <keys> <add thumbprint="A8F1A0A474C8FF51F5B84945B6504813687733B8" /> </keys> <validIssuers> <add name=" http://AD FS.server.com/AD FS/services/trust" /> </validIssuers> </authority> </issuerNameRegistry> <!--certificationValidationMode set to "None" by the the Identity and Access Tool for Visual Studio. For development purposes.--> <certificateValidation certificateValidationMode="None" /> </identityConfiguration> </system.identityModel>
On the website, navigate to the login page. Now you’ll see Federation under External Logins. After a successful login, the claims can be retrieved in back in code by using the below line.
var claimsIdentity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity;
You can verify the user’s identity with the claims.
After setting these values, execute the application and navigate to the login page.
Click the Federation button. This will navigate to the AD FS server.
Using a valid domain account, login to the AD FS. You will navigate back to the application. The application contains the claims email, name and other data. Use this data to sign in and navigate to the home screen!
Looking for more tech tips? View our related blogs on tech and development