Single sign-on for ASP.Net and SharePoint

Transcription

1 Single sign-on for ASP.Net and SharePoint Author: Abhinav Maheshwari, 3Pillar Labs Introduction In most organizations using Microsoft platform, there are more than one ASP.Net applications for internal or external purposes. With the growing popularity of SharePoint, many organizations also have one or more SharePoint sites for collaboration. So single sign-on becomes an obvious requirement, i.e. the users should be able to access all the systems using the same credentials. Usually a single sign-on solution in such an environment will need to satisfy the following conditions: a) Works across different browsers b) Uses known and proven security mechanisms c) Ease of implementation and maintenance d) Minimal modification in the source code of applications Fortunately Microsoft provides several solutions to solve this problem. Two of the approaches are outlined in this paper. First approach leverages forms authentication using a common machine key across all ASP.Net applications and SharePoint. Second approach uses the Active Directory Federation Services (ADFS 2.0) to ensure that all applications use a central token service to do the claim based security. Since Active Directory is a user credentials store, we have used it as an example throughout this paper, though the approach can be easily modified to include your custom authentication solution. Forms authentication using same machine key The usual flow for forms authentication is as follows. The web browser displays the Login.aspx page to the user. When the user is authenticated (say using Active Directory), a forms authentication cookie is sent to the browser. This cookie is included by the browser for all subsequent requests. As we know, ASP.Net uses <machinekey> element in the web.config file to configure the keys to use for encryption and decryption of Forms authentication cookie data and

2 view-state data and for verification of out-of-process session state identification. This leads us to the following approach. 1: GET /default.aspx 2. Login.aspx 6. Cookie 3: POST username/password 5: Create encrypted cookie 4: Authenticate Active Directory 7: GET /default.aspx Cookie 9. default.aspx 8: Decrypt cookie, validate If in each of our web applications, we set the same machinekey, those applications can read Forms authentication cookies set by other applications. So after the users have been authenticated and a cookie saved on its computer, the other applications with the same <machinekey>, can accept this cookie as a valid authentication ticket. So there would be no need to re-login in other applications with the same <machinekey> in their web.config file, provided the following conditions are met: a) applications are authenticating the same users b) applications are hosted on the same domain so that browser sends the cookies c) cookies are valid for all the subdomains in the entire domain The flow is as follows: Step 1-3 Step 4-6 Step 7 The user browses to app1.fabrikam.com. This site opens up an authentication form where the user enters the credentials. The user is authenticated by app1.fabrikam.com using Active Directory membership provider. Forms authentication cookie containing the username is generated and sent back to the browser. This cookie is valid for all sub-domains The user browses to sharepoint1.fabrikam.com. The browser sends the forms

3 Step 8-9 authentication cookie from the previous step to this application as well. The application is able to decrypt the forms authentication cookie because it has the same machine key. Since the username is valid, the application allows the user to view the default page without displaying the login page. Similar configuration with a SharePoint web application will result in the user being able to login to SharePoint without providing the credentials again. Implementation of same machine key approach Prerequisites Active Directory installed on your domain ASP.Net application should be hosted on a sub-domain, for example, aspnet1.fabrikam.com SharePoint installation should be hosted on the sub-domain, for example, sharepoint1.fabrikam.com Let us first take up the configuration of a simple ASP.Net application using same machine key approach. 1. Configure the application to use forms authentication. This is necessary because this approach relies on cookie based authentication. <system.web> <authentication mode="forms"> <forms loginurl="~/login.aspx" timeout="2880" domain=".fabrikam.com"/> </authentication> </system.web> 2. Add the Active Directory connecting string. This element is placed outside the system.web element. The connection string should be similar to the following, but you may need to figure out the exact string for your organization. <connectionstrings> <add name="adconnectionstring" connectionstring="ldap:// /ou=engineering,dc=fabrikam"/> </connectionstrings> 3. Add a membership provider to authenticate against your active directory. Make sure that you provide a username and password which has permissions to access

4 the Active Directory users. In our case, it was the domain administrator username and password. Another important point is that you need to check the correct version of the membership provider present in your installation of.net framework. <membership defaultprovider="myadmembershipprovider"> <providers> <add name="myadmembershipprovider" type="system.web.security.activedirectorymembershipprovider, System.Web, Version= , Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionstringname="adconnectionstring" connectionusername="domain-admin" connectionpassword="domain-admin-password" connectionprotection="none"/> </providers> </membership> 4. Configure the value of machine key manually inside the system.web element. This would be same across all ASP.Net applications that use single sign on. <machinekey validationkey="282487e295028e59b8f411acb689ccd6f39ddd21e6055a3ee adf21b58 0D8587DB675FA02F E25309CCCDB647174D5B3D0DD9141" decryptionkey="8b cbca902b1a0925d40faa00b353f2df4359d2099" validation="sha1"/> 5. Verify that you are able to login to the application using your Active Directory credentials. You may need to provide the username in the format. Now we apply the same approach to a SharePoint hosted on another sub-domain. The approach remains essentially the same, but the configuration required in case of SharePoint has many more steps. 1. The very first step is to create a web application AND create that with claims authentication mode. Once we select the authentication mode to be claims, Windows Authentication is also plugged in as one of the provider. Check the Enable Windows Authentication check box if you d like Windows Authentication ALSO enabled for this web application.

5

6 You can choose the other values as you d normally would and create the new web application. Once the web application is created, we ll first configure this web application for claims authentication using Active Directory Membership Provider and then create a site collection. There are 3 web.config files we need to edit for enabling claims: a) The config file of the Central Administration site. b) The config file of the Web Application. c) The config file of the STS (Security Token Service) Application. This is important because it is this service that will ensure claims tokens are being passed correctly between the provider (in our case Active Directory) and the consumer (Central Administration site and our Web Application). STS Application manages all of these interactions for us. 2. Open the web.config file of your SharePoint 2010 Central Administration site and add the following entries. The entries would be same as those added for the ASP.Net application. <connectionstrings> <add name="adconnectionstring" connectionstring="ldap:// /dc=fabrikam"/> </connectionstrings> 3. Also add the membership provider just like the ASP.Net application. <membership defaultprovider="myadmembershipprovider"> <providers> <clear/> <add name="myadmembershipprovider" type="system.web.security.activedirectorymembershipprovider, System.Web, Version= , Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionstringname="adconnectionstring" connectionusername="domain-admin" connectionpassword="domain-admin-password" connectionprotection="none" enablesearchmethods="true" attributemapusername="userprincipalname" /> </providers> </membership>

7 4. The next step is to configure the web application. Open the web.config file of the web application you just created and add the following entries for connection string. The entries would be same as those added for the ASP.Net application. <connectionstrings> <add name="adconnectionstring" connectionstring="ldap:// /dc=fabrikam"/> </connectionstrings> 5. Search for the membership provider and add the Active Directory membership provider similar to what we did for the Central Administration. The difference in this case is that the SharePoint provider is already plugged in and it will continue being the default provider. 6. Configure the domain in the forms authentication <authentication mode="forms"> <forms loginurl="~/account/login.aspx" timeout="2880" domain=".fabrikam.com"/> </authentication> 7. Configure the machine key in the config file <machinekey validationkey="282487e295028e59b8f411acb689ccd6f39ddd21e6055a3ee adf21 B580D8587DB675FA02F E25309CCCDB647174D5B3D0DD9141" decryptionkey="8b cbca902b1a0925d40faa00b353f2df4359d2099" validation="sha1"/> 8. The next thing to do is to get your provider entry in the STS application s web.config file. Open Internet Information Services (IIS) Manager on your

8 SharePoint 2010 box and find the STS application (shown in Image7). Now rightclick to Explore and open the web.config file. 9. Add the following entries for connection string in the config file. The entries would be same as those added for the ASP.Net application. <connectionstrings> <add name="adconnectionstring" connectionstring="ldap:// /dc=fabrikam"/> </connectionstrings> 10. Add a system.web element if not already present in the file and add the ASP.Net membership provider just like the previous steps. <membership defaultprovider="myadmembershipprovider"> <providers> <clear/> <add name="myadmembershipprovider" type="system.web.security.activedirectorymembershipprovider, System.Web, Version= , Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionstringname="adconnectionstring" connectionusername="domain-admin" connectionpassword="domain-admin-password" connectionprotection="none" enablesearchmethods="true" attributemapusername="userprincipalname" /> </providers> </membership>

9 11. Restart IIS using the IIS Management Console. 12. First, go to the Web Applications Management page in Central Administration site, click the web application you want to enable Form based Authentication claims on and choose Authentication Providers from the ribbon. From the Authentication Providers dialog, choose Default. Scroll a bit down to find Identity Providers section. Check Enable ASP.NET Membership and Role Provider (NOTE: You can also do this at the time of creating this web application) and type in the name of your provider). The name MyADMembershipProvider has been used in the examples. 13. Now, hit User Policy ribbon option in the Web Applications Management page having selected your web application. Hit Add Users in the Policy for Web Application dialog. Hit Next in Add Users dialog. Use the Browse button in the Choose Users people picker control. Notice the Select People and Groups dialog that comes up is changed. Choose the section Forms Auth search for a user to add.

10 Testing the same machine key approach Now we can test the single sign-on. Try to browse the ASP.Net application. It will open up a form for authentication. Once you are authenticated and browse to the SharePoint, you would automatically be signed in. The machine key needs to be encrypted by an authorized user and then configured in an encrypted section in the web.config file by the administrator. This way no one gains access to the machine key. Neither is the key transmitted over the wire. Active Directory Federation Services ADFS is the Microsoft implementation of the WS-Federation passive protocol in which the client interacts with the application and the Token service using cookies and redirects. In the AD FS 2.0 setup, the application becomes a trusted relying party of the token service provided by AD FS 2.0 and is configured to authenticate using the trusts tokens issued by AD FS 2.0. It follows that if several applications are configured to use the same token service and the user has successfully logged into one application, as soon as the user browses to another application, browser would send the same token to second application. Since the second application would be able to validate that token with the token service, it will allow the user to login without asking for credentials again. Step 1-3 The user browses to app1.fabrikam.com. This site opens up an authentication form where the user enters the credentials.

11 Step 4-6 Step 7 Step 8-9 The user is authenticated by app1.fabrikam.com using Active Directory membership provider. Forms authentication cookie containing the username is generated and sent back to the browser. This cookie is valid for all sub-domains The user browses to sharepoint1.fabrikam.com. The browser sends the forms authentication cookie from the previous step to this application as well. The application is able to decrypt the forms authentication cookie because it has the same machine key. Since the username is valid, the application allows the user to view the default page without displaying the login page.