(Note: Updates after first post are in red - Dec 2004)
Every now and then I see people asking for some way to achieve single sign-on using Forms Authentication so you may reuse the Forms ticket with along several sites. It happens that you can have this functionality (not provided out of the box) with just a few tweaks.
Downloads
You can download the code sample for the SSO Forms Authentication from here. The example code is provided as source code that you can use "as is" or customize it for your own applications.
SSO Sample
The sample that you can download form the above link, has two sites. The one named “FormsAuth2” is the entry point site that will call the login page located on the “FormsAuth” site. After the authentication process, the Forms ticket will be reused from the first site “FormsAuth2” with all the user name and roles info inside it. After diving into the details, let me say that these two sites are structured in two areas (public and private) in order to clearly differentiate between the publicly accessible areas and restricted areas that require authenticated access andSecure Sockets Layer (SSL). I use separate subfolders beneath the virtual root folder of both applications to hold restricted pages such as the login form and other sample form with checkout links and the like, that needs to be secured by using HTTPS. By doing so, I can use HTTPS for specific pages without incurring the SSL performance overhead across the entire site.
Configuration
The configuration showed on the following figure is a sample of how you can set the Forms Authentication attributes with security in mind. You should follow these hints for SSO Forms Auth. First of all, you should have the same settings (see forms element attributes) that are listed below on every site that you want to adhere to SSO.· Name· Protection· PathThe machineKey element might be configured on the machine.config file or on every web.config application file. In the first scenario, you may have the encryption key set to something like this (this is the default setting, albeit useless for this scenario):
| <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey= "AutoGenerate,IsolateApps" validation="SHA1"/> |
The "IsolateApps" means that a different key will be AutoGenerated for *each* application. You can either remove the isolateApps option (for apps on the same machine) or insert a specific key value for it to use (for apps on different boxes). This last option is the one that is used on following the config sample.
|
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginUrl="Secure\login.aspx" protection="All" requireSSL="true" timeout="10" name="FormsAuthCookie" path="/FormsAuth" slidingExpiration="true" /> </authentication> <!-- The virtual directory root folder contains general pages. Unauthenticated users can view them and they do not need to be secured with SSL. --> <authorization> <allow users="*" /> <!-- Allow all users -->
</authorization> <machineKey validationKey="C50B…CABE" decryptionKey= "8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F" validation="SHA1"/> </system.web> <!-- The restricted folder is for authenticated and SSL access only. All pages on the Secure subfolder will be under SSL access. -->
<location path="Secure" >
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</location> </configuration> |
Note: Check ouy the path attribute. This should be aligned with the app name. If you want to have SSO on every app, just leave the default value "/".
Principal Creation
After gathering the user credentials you will perform the authentication process and after that you will retrieve the user roles if you want to use the .NET role authorization pattern. This implies the creation of an Identity and a Principal object that will contain this data. So on the login page server side and after the auth process you will get the Forms ticket and save there your roles info and may be any other user profile related data (beware of size constrains, less than 4KB).
| // Do auth with your preferred auth method WindowsIdentity identity = WinAccessHelper.LogonUser( UserId, Password ); // Add roles string[] roles = WinAccessHelper.Roles( new WindowsPrincipal( identity ) ); HttpCookie cookie = FormsAuthentication.GetAuthCookie( UserId.Text, false ); FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(cookie.Value); // Store roles inside the Forms cookie. FormsAuthenticationTicket newticket = new FormsAuthenticationTicket( ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, ticket.IsPersistent, String.Join( "|", roles), ticket.CookiePath); cookie.Value = FormsAuthentication.Encrypt(newticket); Context.Response.Cookies.Set(cookie); Response.Redirect( FormsAuthentication.GetRedirectUrl( newticket.Name, newticket.IsPersistent ) ); // For different domains, should use the cookie domain//HttpCookie formsCookie = FormsAuthentication.GetAuthCookie( UserId.Text, false );//formsCookie.Domain = "localhost.com";//Response.AppendCookie( formsCookie );//Response.Redirect( FormsAuthentication.GetRedirectUrl( UserId.Text, false ) );//FormsAuthentication.RedirectFromLoginPage( UserId.Text, false ); |
Principal Retrieving
On each AuthenticateRequest event of every SSO “federated” site you may retrieve your saved user info and create your Principal object and load them onto the User object of the current HttpContext instance. This is accomplished on the following figure.
| protected void Application_AuthenticateRequest(Object sender, EventArgs e){
if (Context.Request.IsAuthenticated) { // retrieve user's identity from httpcontext user
FormsIdentity ident = (FormsIdentity)Context.User.Identity;
// retrieve roles from the authentication ticket userdata field string[] arrRoles = ident.Ticket.UserData.Split(new char[] {'|'}); // create principal and attach to user Context.User = new System.Security.Principal.GenericPrincipal(ident, arrRoles); }} |
Multiple Domain Scenarios
For Domain wide authentication scenarios, you can set domain-wide cookie only for second level domain, or for third level domain if second level domain contains three or less characters. It means that you cannot set cookie for domain "com" or "co.uk", but can for "example.com" or "example.co.uk". You can find a good example of this here.Hopefully this sample will give you a good idea of how to implement a SSO scenario with Forms Authentication. Enjoy it! This posting is provided "AS IS" with no warranties, and confers no rights.