Configure Web SSO authentication by using ADFS (Windows SharePoint Services)

Applies To: Windows SharePoint Services 3.0

Topic Last Modified: 2010-11-08

In this article:

• About federated authentication systems

• Before you begin

• Configuring your extranet Web application to use Web SSO authentication

• Allowing users access to your extranet Web site

• Working with the People Picker

• Working with E-mail and UPN claims

• Working with groups and organizational claims

About federated authentication systems

Windows SharePoint Services 3.0 provides support for federated authentication scenarios where the authentication system is not local to the computer that hosts Windows SharePoint Services 3.0. Federated authentication systems are also known as Web single sign-on (SSO) systems. With Active Directory Federation Services (ADFS), people in one company can access servers hosted by a different company by using their existing Active Directory accounts. ADFS also establishes a trust relationship between the two companies and a seamless one-time logon experience for end users. ADFS relies on 302 redirects to authenticate end users. Users are issued an authentication token (cookie) after they are authenticated.

Before you begin

Before you use ADFS to configure Web SSO authentication for your extranet Web application, you should become familiar with the following resources:

• Microsoft SharePoint Products and Technologies Team Blog entry about configuring multiple authentication providers (https://blogs.msdn.com/sharepoint/archive/2006/08/16/configuring-multiple-authentication-providers-for-sharepoint-2007.aspx).

• Step-by-Step Guide for Active Directory Federation Services (https://go.microsoft.com/fwlink/?LinkId=145396). The server names and examples used in this article are based on this step-by-step guide, which describes setting up ADFS in a small lab environment. In this environment, a new server named Trey-SharePoint is joined to the Trey Research forest. Follow the steps in the step-by-step guide to configure your ADFS infrastructure. However, because this article describes how to configure Windows SharePoint Services 3.0 in a claims-aware application mode, you do not have to implement all the steps for building Windows NT token agent applications that are described in the step-by-step guide.

Configuring your extranet Web application to use Web SSO authentication

1. Install the Web Agent for Claims Aware Applications.

2. Download and install the hot fix for ADFS described in The role provider and the membership provider cannot be called from Windows SharePoint Services 3.0 on a Windows Server 2003 R2-based computer that is running ADFS and Microsoft Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?LinkId=145397). This hot fix will be included in Windows Server 2003 Service Pack 2 (SP2).

3. Install Windows SharePoint Services 3.0, configure all the services and servers in the farm, and then create a new Web application. By default, this Web application will be configured to use Windows authentication, and it will be the entry point through which your intranet users will access the site. In the example used in this article, the site is named http://trey-moss.

4. Extend the Web application that you created in step 2 in another zone. On the Application Management page in the SharePoint Central Administration Web site, click Create or Extend Web Application, click Extend an existing Web Application, and then do the following:

   1. Add a host header. This is the DNS name by which the site will be known to users in the extranet. In this example, the name is extranet.treyresearch.net.

   2. Change the zone to Extranet.

   3. Give the site a host header name that you will configure in DNS for your extranet users to resolve against.

   4. Click Use Secure Sockets Layer (SSL), and change the port number to 443. ADFS requires that sites be configured to use SSL.

   5. In the Load Balanced URL box, delete the text string :443. Internet Information Services (IIS) will automatically use port 443 because you specified the port number in the previous step.

   6. Complete the rest of the steps on the page to finish extending the Web application.

5. On the Alternate Access Mappings (AAM) page, verify that the URLs resemble the following table.

   Internal URL	Zone	Public URL for Zone
   http://trey-moss	Default	http://trey-moss
   https://extranet.treyresearch.net	Extranet	https://extranet.treyresearch.net

6. Add an SSL certificate to the Extranet Web Site in IIS. Make sure that this SSL certificate is issued to extranet.treyresearch.net, because this is the name that clients will use when they access the sites.

7. Configure the Authentication provider for the extranet zone on your Web application to use Web SSO by doing the following:

   1. On the Application Management page of your farm’s Central Administration site, click Authentication Providers.

   2. Click Change in the upper-right corner of the page, and then select the Web application on which you want to enable Web SSO.

   3. In the list of two zones that are mapped for this Web application (both of which should say Windows), click the Windows link for the Extranet zone.

   4. In the Authentication Type section, click Web Single Sign On.

   5. In the Membership provider name box, type

      SingleSignOnMembershipProvider2

      Make a note of this value; you will be adding it to the name element of the <membership> section in the web.config files that you will edit later in this procedure.

   6. In the Role manager name box, type

      SingleSignOnRoleProvider2

      Make a note of this value; you will be adding it to the name element of the <roleManager> section in the web.config files you will edit later in this procedure.

   7. Make sure the Enable Client Integration setting is set to No.

   8. Click Save.

Your extranet Web application is now configured to use Web SSO. However, at this point, the site will be inaccessible because no one has permissions to it. The next step is to assign permissions to users so that they can access this site.

Allowing users access to your extranet Web site

1. Use a text editor to open the web.config file for the Web site on the default zone that is using Windows authentication.

2. Add the following entry anywhere in the <system.web> node.

   <membership>

   <providers>

   <add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />

   </providers>

   </membership>

   <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">

   <providers>

   <remove name="AspNetSqlRoleProvider" />

   <add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />

   </providers>

   </roleManager>

3. Change the value for fs-server to reflect your resource Federation Server (adfsresource.treyresearch.net). Ensure that you entered the correct membership provider and the role manager names on the Central Administration Authentication Providers page. When this entry is added to web.config, the People Picker on the default zone site that is using Windows authentication is able to know about the ADFS providers and, therefore, can resolve the ADFS claims. This enables you to grant permissions to the ADFS claims on your Web site.

4. Grant ADFS claims access to the site by doing the following:

   1. Navigate to the Web site on the default zone that uses Windows authentication as an administrator of the site.

   2. Click the Site Actions menu, point to Site Settings, and then click Advanced Permissions.

   3. Click New, and then click Add Users.

   4. To add a user claim, specify their e-mail address or User Principal Name in the Users/Groups section. If both UPN and e-mail claims are sent from the federation server, then SharePoint will use UPN to verify against the MembershipProvider. Therefore, if you want to use e-mail, you will have to disable the UPN claim in your federation server. See “Working with UPN and e-mail Claims” for more information.

   5. To add a group claim, type the name of the claim you want the SharePoint site to use in the Users/Groups section. For example, create an organizational group claim named Adatum Contributers on the Federation Server. Add the claim name Adatum Contributers to the Sharepoint site as you would a Windows user or group. You can assign this claim Home Members [Contribute], and then any user who accesses the SharePoint site by using this group claim will have Contributor access to the site.

   6. Select the appropriate permission level or SharePoint group.

   7. Click OK.

5. Use the text editor of your choice to open the web.config file for the extranet site, and add the following entry in the <configSections> node.

   <sectionGroup name="system.web">

   <section name="websso" type="System.Web.Security.SingleSignOn.WebSsoConfigurationHandler, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />

   </sectionGroup>

6. Add the following entry to the <httpModules> node

   <add name="Identity Federation Services Application Authentication Module" type="System.Web.Security.SingleSignOn.WebSsoAuthenticationModule, System.Web.Security.SingleSignOn, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, Custom=null" />

   Note

   The ADFS authentication module should always be specified after the Sharepoint SPRequest module in the <httpModules> node of the web.config file. It is safest to add it as the last entry in that section.

7. Add the following entry anywhere under the <system.web> node.

   <membership defaultProvider="SingleSignOnMembershipProvider2">

   <providers>

   <add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

   </providers>

   </membership>

   <roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">

   <providers>

   <add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

   </providers>

   </roleManager>

   <websso>

   <authenticationrequired />

   <auditlevel>55</auditlevel>

   <urls>

   <returnurl>https://your_application</returnurl>

   </urls>

   <fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>

   <isSharePoint />

   </websso>

   Note

   Change the value for fs-server to your Federation Server computer, and change the value of your_application to reflect the URL of your extranet Web application.

8. Browse to the https://extranet.treyresearch.net Web site as an ADFS user who has permissions to the extranet web site.

About using Central Administration

You can also use Central Adminstration policy to grant rights to ADFS users, but it is best not to use that method for the following reasons:

• Granting rights by policy is a very coarse operation. It allows the user (or group) to have the same set of rights in every Web site, in every site collection on the whole Web application. It should be used very judiciously; in this particular scenario, we can grant access to ADFS users without using this method.

• After the sites are being used in an extranet environment, it is very likely that the internal users will be responsible for granting access to sites and content. Because only the farm administrators have access to the Central Administration site, it makes the most sense that internal users can add ADFS claims from the default zone site that is using Windows authentication.

• As you extend Web applications by using different providers, you can configure one or more of them to be able to find users and groups from various providers that you are using on that Web application. In this scenario, we configured our site that uses Windows authentication in a way that allows users of that site to select other Windows users, Windows groups, and ADFS claims, all from one site.

Working with the People Picker

The People Picker cannot perform wildcard searches for searching roles. If you have a Web SSO Role provider role named Readers, and you type Read in the People Picker search dialog box, it will not find your claim. If you type Readers, it will. This is not a bug, you just cannot perform wildcard searching by using the Role provider.

Command-line executable files like stsadm.exe will not be able to resolve the ADFS claims by default. For example, you might want to add a new user to the extranet site by using the stsadm.exe –o adduser command. To enable Stsadm (or other executable file) to resolve users, create a new config file by doing the following:

• Create a new file named stsadm.exe.config in the same directory where stsadm.exe is located (%programfiles%\Common Files\Microsoft Shared Debug\Web Server Extensions\12\BIN). Add the following entry in the stsadm.exe.config file:

  <configuration>

  <system.web>

  <membership defaultProvider="SingleSignOnMembershipProvider2">

  <providers>

  <add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />

  </providers>

  </membership>

  <roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">

  <providers>

  <add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />

  </providers>

  </roleManager>

  </system.web>

  </configuration>

  Note

  Change the value of fs-server to your resource Federation Server (adfsresource.treyresearch.net).

Working with E-mail and UPN claims

To configure whether or not the Federation Server is enabled to send e-mail or UPN claims to Windows SharePoint Services 3.0, perform the following procedure.

Configure E-mail and UPN claims on a Federation Server

1. From Administrative Tools on your Federation Server, open the ADFS snap-in.

   Note

   You can also open the ADFS snap-in by typing ADFS.MSC in the Run dialog box.

2. Select your Windows SharePoint Services 3.0 application node (your application should already be added to the list of nodes).

3. In the claims list on the right, right-click E-mail, and select Enable or Disable.

4. In the claims list on the right, right-click UPN, and select Enable or Disable.

   Note

   If both UPN and E-mail are enabled, Windows SharePoint Services 3.0 will use UPN to perform user claim verification. Therefore, when configuring the Windows SharePoint Services 3.0, be careful about which user claim you enter. Also note that the UPN claim will only work consistently if the UPN suffixes and the e-mail suffixes that are accepted by the Federation Server are identical. This is because the membership provider is e-mail based. Because of this complexity in configuring UPN claims, e-mail is the recommended user claim setting for membership authentication.

Working with groups and organizational group claims

In Windows SharePoint Services 3.0, rights can be assigned to Active Directory groups by adding them to a SharePoint group or directly to a permission level. The level of permissions a given user has on a site is calculated based on the Active Directory groups the user is a member of, the SharePoint groups the user belongs to, and any permission levels that the user has been directly added to.

When you use ADFS as a role provider in Windows SharePoint Services 3.0, the process is different. There is no way for the Web SSO provider to directly resolve an Active Directory group; instead, it resolves membership by using organizational group claims. When you use ADFS with Windows SharePoint Services 3.0, you must create a set of organizational group claims in ADFS. You can then associate multiple Active Directory groups with an ADFS organizational group claim.

For group claims to work with the latest version of ADFS, you need to edit the web.config file for the ADFS application in IIS on your ADFS server.

Open the web.config file and add <getGroupClaims /> to the <FederationServerConfiguration> node inside the <System.Web> node, as shown in the following example.

<configuration>
     <system.web>
          <FederationServerConfiguration>
               <getGroupClaims />
          </FederationServerConfiguration>
     </system.web>
</configuration>

In the Adatum (Account Forest), do the following:

1. Create an Active Directory group named Trey SharePoint Readers.

2. Create an Active Directory group named Trey SharePoint Contributors.

3. Add Alansh to the Readers group and Adamcar to the Contributors group.

4. Create an organizational group claim named Trey SharePoint Readers.

5. Create an organizational group claim named Trey SharePoint Contributors.

6. Right-click the Active Directory account store, and then click New Group Claim Extraction.

   1. Select the Trey SharePoint Readers organizational group claim, and then associate it with the Trey SharePoint Readers Active Directory group.

   2. Repeat step 6, and then associate the Trey SharePoint Contributors group claim with the Trey SharePoint Contributors Active Directory group.

7. Right-click the Trey Research Account Partner, and then create the outgoing claim mappings:

   1. Select the Trey SharePoint Reader claim, and then map to outgoing claim adatum-trey-readers.

   2. Select the Trey SharePoint Contributor claim, and then map to outgoing claim adatum-trey-contributors.

On the Trey Research side, start ADFS.MSC, and then do the following:

1. Create an organizational group claim named Adatum SharePoint Readers.

2. Create an organizational group claim named Adatum SharePoint Contributors.

3. Create incoming group mappings for your claims:

   1. Right-click the Adatum account partner, and then click Incoming Group Claim Mapping.

   2. Select Adatum SharePoint Readers, and then map it to the incoming claim name adatum-trey-readers.

   3. Select Adatum SharePoint Contributors, and then map it to the incoming claim name adatum-trey-contributors.

4. Right-click the Windows SharePoint Services 3.0 Web application, and then click Enable on both the Reader and Contributor claims.

Browse to the http://trey-moss site on the Trey Research side as the site administrator, and then do the following:

1. Click the Site Actions menu, point to Site Settings, and then click People and Groups.

2. If it is not already selected, click the Members group for your site.

3. Click New, and then click Add Users on the toolbar.

4. Click the address book icon next to the Users/Groups box.

5. In the Find box in the People Picker dialog box, type

   Adatum SharePoint Readers

   In the Give Permission section, select SharePoint group home Visitors [Readers].

6. In the Find box, type

   Adatum SharePoint Contributors

   In the Give Permission section, select SharePoint group home Members [Contribute].

Download this book

This topic is included in the following downloadable book for easier reading and printing:

• Deployment for Windows SharePoint Services 3.0 technology

See the full list of available books at Downloadable content for Windows SharePoint Services 3.0.