What is Single Sign On?
SSO is an authentication approach that allows users to login to multiple applications with the same credentials and via the same login/identity management system.
Examples of SSO applications include the Google suite whereby to be granted access, you sign in once to YouTube, Gmail, docs etc.
Benefits and Reasons for Usage
SSO applications mean that the sensitive login credentials are reduced to one set.
This means that enterprise security is increased due to the vulnerabilities exposed when signing into a system becoming less common.
As well as security, SSO also improves usability and minimises user disruption.
Furthermore, money can be saved with the hassle of maintaining multiple user login systems and their sensitive data eradicated.
How to implement SSO in a .NET Framework Application
For this example, we will be implementing SSO across multiple projects within the same domain.
If your intention is to achieve SSO functionality across different domains, you should investigate IdentityServer3 (<= .Net 4.6) or IdentityServer4 (Core).
Setting Up
To setup SSO, the project must be created with the authentication type as either individual account or identity platform.
Additionally, as per standard Identity Framework convention, any methods/controllers that require the user to be signed in, require an [authorize] data annotation declared above. On the other hand, if an entire controller is marked with the authorize annotation, individual methods can overwrite this with an [AllowAnonymous] annotation.
Cookie authentication needs to be enabled in all projects with the login path, cookie name, and cookie domain matching the web.configs configuration (explained later).
This can be done inside the startup.auth.cs file within the app_start folder.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
CookieName = "SingleSignOn",
CookieDomain = "domain.co.uk",
});
Additionally, in all projects sharing the login information, the following forms authentication tag needs to be added inside the web.config.
<authentication mode="Forms">
<forms cookieless="UseCookies" domain="domain.co.uk" loginUrl="https://domain.co.uk/login" name="SingleSignOn" slidingExpiration="false" timeout="60"></forms>
</authentication>Most attributes are self-explanatory, apart from ‘sliding expiration’.
What is Sliding Expiration?
When set to true, if half or more of the timeout/expiration period is reached when a user interacts with the system, the timer is extended and reset.
For example, when enabled, if a user signs in at 10:00 and interacts with the system at or after 10.31 minutes, the expiration timer will be extended to 11.01.
Otherwise, when disabled, the timer will not be reset.
Machine Key and Validation Key
In order for the shared login functionality to be applied, matching machine key and validation values need to be entered into each project’s web.config.
<machineKey validationKey="E35..." decryptionKey="9FS..." validation="SHA1" decryption="AES" />This can be generated from within IIS as explained here.
The decryption and validation methods for the machine key also need to be defined in this tag.
The types of validation available are outlined by microsoft.
Cookies
.NET Identity Framework can manage the login state of an application via a ‘cookieless’ or ‘use cookies’ state.
For this tutorial we will use cookies.
However, for reference, when using cookieless SSO, the forms authentication ticket will be stored within the URLs instead of inside an encrypted cookie. For more information, read this article.
Return URL
The return URL is the URL of the page that the user is currently within when they are timed out or sign out themselves.
The action result that returns the login page needs to accept a return URL parameter from the external system so that the user gets redirected back to the same page they were on.
This return URL can then be assigned to a ViewBag, so it can used when the user is logged back in (inside the login post request).
var result = await SignInManager.PasswordSignInAsync(model.UserName…);
switch (result)
{
case SignInStatus.Success:
return Redirect(returnUrl);
case …
}
Return URL Across Multiple Subdomains
If the return URL exists outside the login pages sub domain, extra code needs to be written to allow this.
This is because the return URL will be invalid across sub domains.
For example, if the user is signed out of sub.domain.co.uk/current, but the login page is within domain.co.uk/login. Once signed back in, the user will be redirected to domain.co.uk/current instead of sub.domain.co.uk/current.
To solve this, the loginUrl attribute value within the forms tag in the webconfig can be extended to include another parameter to identify the origin subdomain. As follows:
...loginUrl=”https://domain.co.uk/returnUrlSubDomain=https://sub.domain.co.uk”...Then, the login pages get request action result needs to accept this additional sub domain value, and prepend it to the returnUrl.
public ActionResult Login(string returnUrl, string returnUrlSubDomain)
{
if (returnUrlSubDomain != null)
{
returnUrl = returnUrlSubDomain + returnUrl;
}
}…
}
I hope you have enjoyed the post.
Icons made by Freepik from www.flaticon.com