Configuration and Deployment Considerations for Federation Extensions for SharePoint 3.0

The sections in this topic discuss configuring user access for federated SharePoint Web applications, configuring Federation Extensions for SharePoint 3.0 in a farm environment, and important considerations to be aware of when deploying Federation Extensions for SharePoint 3.0.

Configuring User Access

On the federated SharePoint Web application, the SharePoint engine queries the claims-based role and membership providers to authorize user access. As a result, federated users must be configured using claims-based role and membership providers. As part of configuring SharePoint, SharePointFedUtil modifies the SharePoint Central 3.0 Administration site’s web.config file to be aware of these role and membership providers. As a result, you can configure access for a federated user using the Administration Web site as follows:

1. Open the SharePoint Central 3.0 Administration Web site.

2. Go to the Application Management tab.

3. Select Policy for web application under Application security.

4. Click Add Users.

5. Select the appropriate Web application.

6. Select the proper zone Z. Note that you will not be able to use “All Zones”. Click Next.

7. If you want to configure access based on a particular role claim value (such as “Domain Admins”), type in Role#Domain Admins.

8. If you want to configure access based on particular user name (such as “frank@fabrikam.com”), then type in frank@fabrikam.com.

9. Specify the permissions to be given to the user. Click Finish.

Typically, the previous steps are used to create a “federated administrator” who can then configure access for the rest of the federated users, using either roles or names.

Note

If you are deploying this package in a SharePoint Farm environment, the site collection administrator can grant access to the federated user using either roles or names.

Deployment Considerations

The following are considerations to keep in mind when you are enabling the federation scenario for existing SharePoint deployments:

• Keep the authentication methods for the default zone of the Web application as Windows Integrated/NTLM authentication. This is because certain SharePoint features, such as search, require Windows Integrated/NTLM authentication.

• Enable the federation scenario only to the extranet or internet zone of the application. It is recommended to extend your SharePoint application’s default zone as extranet or internet zone and then configure that extended zone for federation. Note that while extending the application, you can keep it in Windows authentication mode and then run the SharePoint Federation Utility tool against that application. This tool makes the changes needed to enable federation in that extranet or internet zone of the application.

• Typically, administrators provision users to a SharePoint site at the site collection level. A site collection administrator can still use this approach to provision federated users from the federated Web application. However, by default it is not possible to set up claims-based roles and memberships for federated users through an intranet site. To enable this, modify the intranet site’s web.config file to recognize the claims-based role and membership providers. These changes are similar to those made by SharePoint Federation Utility to the web.config file of the central administration site.

• Install this Federation Extension package on all Web front-end servers in a SharePoint Farm.

• If you have deployed a SharePoint Farm with multiple Web front-end servers, then you must install this Federation Extension package on each server and configure the application on each server.

Farm Environment Configuration

Use the following procedure to implement the Federation Extensions for SharePoint 3.0 in a Farm Environment.

By default, Federation Extensions for SharePoint 3.0 are not able to run in a farm environment. These are constraints imposed by the default behavior of the WIF Runtime, one of the pre-requisites of the package.

1. Compile the RsaCookieTransformLibrary

   1. Download the zip file that contains the source files for the custom Session Security Token Handler.

   2. Copy the zip file to a temporary folder in the system, where you can compile this C# solution file

   3. Unzip the contents and open RsaCookieTransformLibrary.sln in Visual Studio. Configure the project for strong name signing using the following steps:

      1. In the Solution Explorer, right-click the RsaCookieTransform project and select Properties

      2. In the Property Page, select the Signing tab and then check the Sign the assembly check-box

      3. Click either New… or Browse… to select a strong name key file

   4. Choose a certificate that is available on all computers in the farm and that can be used for securing the cookies issued by the server. Note the subject name for this certificate.

   5. Open the RsaEncryptedSessionSecurityTokenHandler.cs file. In the statement right below the comment TODO: Update the subject name, replace YourUniqueCertificateSubjectName with the subject name of the certificate selected in previous step.

   6. Build the solution to create the RsaCookieTransformLibrary.dll assembly. This assembly has a type named RsaEncryptedSessionSecurityTokenHandler under the namespace RsaCookieTransform. Make a note of these names as these will be needed during configuration edits in step 4.

2. Prepare the assembly using the Global Assembly Cache Tool (Gacutil.exe)

   1. Copy the generated assembly from step 1, RsaCookieTransformLibrary.dll, to a folder, then access the assembly to the system using Gacutil.exe.

   2. Note the Public Key Token value for this assembly by using the command gacutil /l RsaCookieTransformLibrary.

3. Import the cookie encryption certificate

   1. Ensure that the certificate selected in step 1 c is imported to the <LocalMachine\Personal> certificate store with its private key.

   2. Ensure that the user account under which the federated application (example: MySharePointApp) runs, has access to the private key of this certificate.

4. Configure the RSACookieTransform in the application’s configuration file

   1. Add the below configuration snippet to the Microsoft.IdentityModel section of the application’s (example: MySharePointApp) app.config or web.config file. Ensure to update the PublicKeyToken value with the value from step 2.

      <microsoft.identityModel>

      <service>

      …….

      <securityTokenHandlers>

      <!-- Replace the SessionSecurityTokenHandler with your own. -->

      <remove type="Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <add type="RsaCookieTransform.RsaEncryptedSessionSecurityTokenHandler, RsaCookieTransformLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=<tobefilledin>" />

      </securityTokenHandlers>

      … ….

      </service>

      </microsoft.identityModel>

5. Repeat steps 2 through 4 for each computer in the farm.

6. To test this workaround, try accessing your application to verify that the federated authentication is successful.