SURFconext for SharePoint 2010 Setup guide

Transcription

1 SURFconext for SharePoint 2010 Setup guide 2AT b.v. May 2012 Author: Beat Nideröst 1

2 Contents Contents... 2 Introduction Objectives of this guide How to read this guide... 4 Part 1 - Overview of technical components Overview of necessary software component Overview of federated authentication process Mapping of software roles onto Windows servers Hardware and software specifications Hardware specifications Software specifications Web browser requirements for AD FS Web browser support for SharePoint Server Alternate configurations... 8 Part 2 - Setting up your environment Planning and basic setup of your environment Planning of your environment parameters Basic setup of your Windows servers Setting up Windows SharePoint Foundation Install Windows SharePoint Foundation Configure Windows SharePoint Foundation Setting up Active Directory Federation Services (AD FS) Installing AD FS Basic configuration of AD FS Configuring SURFconext as a trusted claims provider in AD FS Exchange of SAML metadata... Error! Bookmark not defined Edit Claim Rules for Claims Provider Trust Switch to SHA1 signing Configure SharePoint 2010 as a Relying Party in AD FS Prerequisites and requirements Configure SharePoint 2010 as a new Relying Party Edit Claim Rules for Relying Party Trust Configure AD FS as a trusted identifying party in SharePoint

3 13 Create a claims-aware SharePoint web application Testing your set-up Providing additional authorization Debugging

4 Introduction 1 Objectives of this guide This guide describes how to setup federated authentication for SharePoint via SURFconext. It configures SURFconext as a federated identity provider for one or more web application zones within an on-premise SharePoint farm. This guide gives you a generic introduction to how federated authentication for SharePoint via SURFconext will work. It will cover the generic architecture of one possible setup, together with its advantages and disadvantages compared to other possible setups. It also details the configuration you have to do on your AD FS server installation and on your SharePoint web application. It will describe how to set up the connection and give you some advice on what (not) to do, what to note and what to be careful about. After you have set up the connection, this guide will describe ways to validate that your setup is working correctly. Finally, there are imperfections inherent to the way AD FS and SharePoint connect to SURFconext. Some functional imperfections are listed in the end of this paper, together with ways to work around these issues. 2 How to read this guide Within this guide, the following terms are used: AD FS This is the Active Directory Federation Services feature that is available for Windows Server 2008 R2. Unless specified otherwise, the 2.0 RTW version with October 2011 cumulative update is implied. SharePoint - This is Windows SharePoint Foundation or SharePoint Server or any other version of the SharePoint 2010 technology family. 4

5 Part 1 - Overview of technical components This guide describes how to setup SURFconext as a federated identity provider for SharePoint. There are several configurations possible for setting up a connection between your on-premise SharePoint farm and SURFconext. This guide assumes a basic configuration with is described below. At the end of this chapter, several alternate scenarios are also described together with their advantages and disadvantages. 3 Overview of necessary software component The steps detailed in this guide can be used to configure any SharePoint 2010 farm to use SURFconext as a federated identity provider. The following software roles are needed in this guide: SharePoint This guide assumes that you are an administrator of a SharePoint 2010 farm and that you would like to provide access to that farm to users of other institutes. It assumes that the other institutes are connected to SURFconext as identity providers. There are a number of different versions of the SharePoint 2010 technology. The most commonly used versions are Windows SharePoint Foundation and SharePoint Server, but any other version can also be used, as long as it is based on SharePoint 2010 technology. Note: There can exist many web applications within a single SharePoint farm and each web application is published via one or more web application zones. Federated authentication is configured at the zone level. This gives you finegrained control over for which applications to enable federated authentication. Active Directory Federation Services SURFconext uses the SAML 2.0 HTTP binding protocols to exchange SAML 2.0 tokens with relying parties. SharePoint 2010 however uses the Windows Identity Framework to accept SAML 2.0 tokens via the WS-Federation passive protocol. The Windows Identity Framework doesn t provide support for the SAML 2.0 HTTP binding protocols and SURFconext doesn t support WS-Federation passive. Therefore, an extra component is needed to connect SharePoint to SURFconext. It is assumed that you use an on-premise AD FS installation to convert the SAML 2.0 HTTP binding protocols into the WS-Federation passive protocol. There are other ways to convert SAML 2.0 HTTP binding protocols into WS-Federation passive. For example, there is a Microsoft Add-on for WIF which is currently available as a beta-version, and there exist many third-party products that can perform the conversion. However, a description of how to configure these alternative solutions is beyond the scope of by this guide. 4 Overview of federated authentication process This chapter describes the federated authentication process as it is executed when using the components described above. 1 User navigates to protected SharePoint server web site. SharePoint server redirects web browser to active directory federation services (AD FS) server. 5

6 2 Web browser requests security token from AD FS server. AD FS server redirects web browser to SURFconext. 3 Web browser requests security token from SURFconext federated authentication service. SURFconext shows Where Are You From screen. User chooses its home institute and SURFconext redirects web browser to the correct identity provider. 4 User authenticates with the home institute. Identity provider issues a security token and redirects web browser back to SURFconext. 5 Federated authentication service issues SURFconext security token based on incoming security token and redirects web browser back to AD FS server. 6 AD FS issues service provider security token based on SURFconext security token and redirects web browser back to SharePoint server 7 SharePoint authenticates user based on AD FS security token and authorizes the user to view protected web site. Web Browser Client 4 2, 6 1, 7 3, 5 Identity Provider Federated Authentication Service Active Directory Federation Services SharePoint Server Client Home Institute SURFconext Service Providing Institute 5 Mapping of software roles onto Windows servers All the different software roles must be hosted on a set of Windows servers. This paragraph describes the configuration of these servers as well as the mapping of the software roles onto these servers. In the setup we describe in this paper, the type of servers used (physical or virtual, or a combination of both) has no impact on the workings of the configuration. The same is true for the type of virtualization (VM-Ware, Hyper-V, Xen, etc.). In our case, all servers are virtual servers, running on a Hyper-V virtualization platform that spans multiple datacenters, connected via low-latency fiber interconnects. The placement of the virtual servers on the host servers is dynamic in this setup and has no impact on the workings of the configuration. The SharePoint farm can consist of a single (virtual) server or it can be scaled out over two or more servers, depending on your performance and resilience requirements. For the purpose of this guide, a single server installation suffices. The guide provides step-by-step instructions for setting up such a single server farm. Setting up a multi-server SharePoint farm is beyond the purpose of this guide. Note: The steps for configuring AD FS as a claims provider for SharePoint can be executed on any SharePoint farm of your liking by logging in on one of the SharePoint front-end servers in your farm that has the Central 6

7 Administration web application installed. Executing the steps on a single front-end server suffices for configuring SURFconext for the entire farm. 6 Hardware and software specifications Below are the hardware and software specifications required for setting up the configuration described in this document. For a background on the required specifications, see: AD FS server - SharePoint server Hardware specifications The setup described in this document consists of two separate windows servers. One server hosts the active directory and active directory federation services. The other server hosts a single-server installation of SharePoint Server. The hardware specifications suggested for testing out this setup are: Specification AD FS server SharePoint Server CPU Quad-core 2 GHz processor Quad-core 2 GHz processor RAM 4 GB 8 GB OS disk size 40 GB 80 GB Network card 1 GBit/s 1 GBit/s Note that for your production environment, other specifications or hardware configurations might be more suitable. For example, for redundancy, you might prefer to use two separate AD FS servers, configured in a single-farm topology with load-balancing between the two servers. The same holds for SharePoint. Also, for performance and data storage reasons, you might consider faster servers with more memory, larger (and possibly additional) hard-disks. Also, you may prefer to distribute roles over multiple servers. E.g., separate AD FS from Active Directory, separate the data storage (SQL server) from AD FS and SharePoint processing, and split the SharePoint farm into front-end web servers, service application servers, search servers etc. For security reasons, you might want to put a hardware or software firewall and/or proxy server (Microsoft TMG, UAG, AD FS proxy server) in front of your SharePoint and/or AD FS farm and consider adding SharePoint content virus scanning functionality. Finally, for a production environment, you will probably consider adding the servers to your configuration management, monitoring and backup facilities. Detailed description of all these possible configurations is out-of-scope of this document. For background information, see: AD FS deployment guide - SharePoint planning and architecture - UAG AD FS Solution guide - 7

8 6.2 Software specifications This document assumes that you are using the following software editions and versions for setting up the described configuration. It is possible to use different editions and/or versions of the software than specified here. However, set-up procedures and screenshots might vary slightly on the exact software you use. Software component Edition Version Windows Server (both servers) Enterprise Edition 2008 R2 with Service Pack 1 Active Directory Federation Windows 2008 R2 x October 2011 Services RTW cumulative update Windows SharePoint Foundation English, no language pack 2010 SP1 with november 2011 cumulative update Note that whereas the original AD FS version is available in the Enterprise and Data Center Editions of Windows Server 2008 R2, AD FS 2.0 is also available for the standard and foundation editions of Windows Server 2008 R Web browser requirements for AD FS Any current browser with JavaScript and cookies enabled should work. Configurations tested by Microsoft are: Browser Windows 7 Windows Vista Internet Explorer 7.0 X X Internet Explorer 8.0 X X FireFox 3.0 X X Safari 3.1 X X 6.4 Web browser support for SharePoint Server Microsoft has tested SharePoint Server on a large number of web browsers and operating systems. For details, see: Alternate configurations There are alternative configurations to connect SharePoint to SURFconext possible: Using Windows Identity Foundation (WIF) - WIF is currently still only available as a beta version and since it runs on the SharePoint front-end servers, it causes for additional load of these servers. However, in this set-up, no AD FS servers are needed. Using third party components such as Ping Federate often, seperate licenses are needed for these components. And in some cases, they require additional servers (instead of the AD FS servers) or they cause extra load on the SharePoint front-end servers. In many cases where an institute has already implemented a Web SSO solution, these components are present already within the institute. In these cases, using those components to connect SharePoint to SURFconext is a straight-forward way to go. For higher reliability, it might be useful to set up a redundant configuration. By using multiple AD FS servers and multiple SharePoint front-end servers, together with database mirroring or 8

9 clustering, a single point of failure can be eliminated at the cost of a more complex configuration with more servers to configured, hosted and maintained. Load is distributed over the multiple AD FS and SharePoint servers via hardware-load-balancing or network-load-balancing, or via a proxy-server like Thread Management Gateway (TMG). AD FS support the use of a stand-alone configuration database or synchronization of it s configuration between multiple instances. SharePoint supports multiple front-end servers by configuring a SharePoint farm and connecting the front-end-servers to the farm. For larger set-ups, adding the servers to a active-directory domain is useful for ease of set-up and maintenance. For more information, consult the installation guides and high availability guides of AD FS and SharePoint on TechNet: (SharePoint) and (AD FS). 9

10 Part 2 - Setting up your environment Setting up your environment consists of the following steps: Perform a basic setup of the Windows servers Setup of Windows SharePoint Foundation Setup of Active Directory Federation Services These steps are described in the chapters below. 7 Planning and basic setup of your environment 7.1 Planning of your environment parameters While setting up your environment, there will be a number of parameters that you have to choose. Some of these parameters are subject to several restrictions for the setup to work properly. If the parameters are chosen incorrectly or not used consistently throughout your configuration, the setup will not work. Also, changing these parameters might cause a lot of rework. Therefore, these parameters are described below so you can choose them now and refer to them when performing the actual configuration. Name Description Example value in this guide AD FS Publishing URL This is the URL at which you will publish your AD FS installation. Web browsers will be redirected from SharePoint to this intermediate URL in order to authenticate via SURFconext. Our suggestion is that you use something like AD FS.<your-institute>.nl or sts.<your-institute>.nl. Note that in order for AD FS to function properly, you need to choose a URL here that you will be able to retrieve a public server certificate for as well as register as a DNS record (A/AAAA or CName). This is necessary since you will set up an actual trust between your AD FS installation and SURFconext and such a trust can only exist between parties with valid DNS entries and server certificates. SharePoint Web Application URL Relying Party Identifier (a.k.a. Realm) Identifying claim type (a.k.a. Incoming claim type) The URL to the root site of the SharePoint web application that will be protected by claims-authentication via SURFconext. Users will type in this URL when they want to connect to your SharePoint installation This is the identifier by which SharePoint identifies itself to AD FS in the token signing request it sends via the web browser of the user. It must be provided to SharePoint while setting up the trust connection to AD FS (realm parameter) and to AD FS when setting up the relying party trust (Relying Party Identifier parameter). Note that you should provide exactly the same value (including casing) in both locations. Otherwise, the mapping might not be complete. This is the claim type name that is used by AD FS and SharePoint as the identifying claim type. The incoming name identifier from SURFconext is mapped onto this claim type for identification of the user by SharePoint. Note that since Windows Identity Foundation (WIF) only accepts type names in URL format, the name identifier that is received by SURFconext is not a valid claim type name for WIF. Therefore, it has to be transformed by AD FS into an acceptable value. urn:sharepoint:portal /ws/identity/claims /wifcompatiblenameid In the remainder of this guide, references to these parameters are be made where appropriate. 7.2 Basic setup of your Windows servers This guide assumes that you have performed a basic installation of your windows servers, configured network access (IP connectivity, DNS resolution, outgoing mail server for SharePoint notifications and alerts, etc.), created a new Active Directory forest with top-level domain on the 10

11 AD FS server and added the SharePoint server to your top level domain. It also assumes that you have updated your operating system with the newest software updates for both Windows and other Microsoft updates. Note: An Active Directory forest is necessary in order to install and use AD FS. 8 Setting up Windows SharePoint Foundation After you have performed the basic server setup and added the SharePoint Server to your top level domain, you can start installing Windows SharePoint Foundation onto your SharePoint server using the following steps: 1) Install Windows SharePoint Foundation 2) Configure Windows SharePoint Foundation 3) Create a Claims-aware SharePoint Web Application 4) Configure claims for SharePoint Each of these steps is described below. 8.1 Install Windows SharePoint Foundation Installing Windows SharePoint foundation consists of the following sub-steps: 1) Download installation files 2) Unpack all installation files 3) Install prerequisites and check again for Windows and Microsoft Updates 4) Install Windows SharePoint Foundation and check again for Windows and Microsoft Updates Each of these sub-steps is described below. Step 1: Download installation files To install an up-to-date version of Windows SharePoint Foundation, each of the following installer packages should be downloaded: Installer package Filename URL Windows SharePoint SharePointFoundation.ex Foundation 2010 e RTM Service Pack 1 December 2011 cumulative update sharepointfoundation201 0sp1-kb x64- fullfile-en-us.exe _intl_x64_zip.exe details.aspx?id= details.aspx?id= SharePoint%20Foundation%202010/sp 2/sharepointfoundation2010kb ful lfil/ /free/441663_intl_x 64_zip.exe Step 2: Unpack all installation files This document assumes that you are performing a clean Windows SharePoint Foundation (WSF) stand-alone installation. This can be done by successively installing and configuring WSF RTM, WSF SP1 and WSF December 2011 cumulative update. However, it is faster and cleaner to create a slipstreamed installer for all three packages combined and install all packages at once, since this skips the build-to-build upgrade steps that are otherwise needed. 11

12 In order to create a slipstreamed installer, the downloaded setup files must be extracted. Follow the procedure below to extract all packages to an installation folder. The commands assume the installation files folder is c:\wsf2010install. If you need to choose another installation files folder, change the commands accordingly. Note that the SP1 and December CU files are extracted into the updates subfolder! 1 Press the Windows Start button, type cmd and press Enter to open a windows command prompt. 2 Type cd followed by the exact path of the folder where you downloaded the files and press Enter to change the current path to the download folder. 3 Type sharepointfoundation.exe /extract:c:\wsf2010install and press Enter to extract the Windows SharePoint Foundation installer files to the c:\wsf2010install folder. 4 Type sharepointfoundation2010sp1-kb x64-fullfile-en-us.exe /extract:c:\wsf2010install\updates and press Enter to extract the Service Pack 1 installer files to the updates subfolder of the c:\wsf2010install folder. 5 Type _intl_x64_zip.exe and press Enter to unzip the December 2011 cumulative update file. Choose the download folder for the unzip destination. 6 Type sharepointfoundation2010-kb fullfile-x64-glb.exe /extract:c:\wsf2010install\updates and press Enter to extract the December 2011 cumulative update installer files to the updates subfolder of the c:\wsf2010install folder. 7 Type exit and press Enter to close the command prompt. Step 3: Install prerequisites and check again for Windows and Microsoft Updates In order to install all Windows SharePoint Foundation prerequisites, open Windows Explorer, browse to the folder where you extracted the WSF installation files (c:\wsfinstall) and doubleclick the PrerequisiteInstaller.exe executable in order to run it. Click Next on the setup wizard and make sure that all prerequisites are installed successfully. In case a prerequisite fails to install, run the wizard again, possibly after a server reboot, until all prerequisites are installed successfully. After all prerequisites are installed, check for Windows and Microsoft updates again and install all updates that might have appeared because of the installation of the prerequisites. Step 4: Install Windows SharePoint Foundation In order to install Windows SharePoint Foundation, open Windows Explorer, browse to the folder where you extracted the WSF installation files (c:\wsfinstall) and double-click the setup.exe executable in order to run it. Navigate through the setup wizard and select to install WSF in a Standalone topology: 12

13 Also, when asked, do NOT run the WSF configuration wizard. Finally, check for Windows and Microsoft updates again and install all updates that might have appeared because of the installation of Windows SharePoint Foundation. 8.2 Configure Windows SharePoint Foundation Now run SharePoint 2010 Products Configuration Wizard from the Start menu. Select all default values in the wizard and wait until Windows SharePoint Foundation has been configured. On the final screen of the configuration wizard (the Configuration Successful screen), make a note of the Central Administration URL, especially the port number. The port number has been chosen randomly during the configuration. You will need to know this port number later on. 9 Setting up Active Directory Federation Services (AD FS) Once SharePoint Foundation is installed, you must set up AD FS in order to convert the SAML 2.0 HTTP binding protocols that SURFconext uses to the WS-Federation passive protocol which SharePoint understands. Setting up AD FS consists of the following five steps: 1) Installing AD FS 2) Performing basic configuration of AD FS 3) Configuring SURFconext as an identifying party 4) Configuring SharePoint as a relying party 13

14 5) Configuring claim mappings to convert SURFconext claims to the format required for SharePoint Each of these steps is described below. 9.1 Installing AD FS 2.0 This paragraph describes the basic steps needed to install AD FS RTW with October 2011 cumulative update onto your windows server. A detailed guide on installing AD FS onto your Windows 2008 R2 server can be found here: Note that Windows Server 2008 R2 SP1 comes packaged with a previous version of AD FS. This version could be installed by adding the corresponding feature from within the Windows Server Manager console. However, this is NOT the correct version. Do NOT add the AD FS feature from the server manager! In case the feature has already been added, remove the feature and reboot your server before you continu! Installing AD FS consists of the following sub-steps: 1) Download the AD FS installation files 2) Run the AD FS setup wizard 3) Apply the October 2011 cumulative update Each of these sub-steps is detailed below. Step 1: Download the AD FS installation files The installation package for AD FS RTW x64 for Windows Server 2008 R2 can be downloaded from the Microsoft site: Be sure to download the installer for the R2 edition Windows Server It is the file with R2 in its name: RTW\W2K8R2\amd64\AD FSSetup.exe Also download the October 2011 cumulative update from the Microsoft site: Fix385088/7600/free/437133_intl_x64_zip.exe Step 2: Run the AD FS setup wizard After downloading the installation packages from the URL above, run AD FSSetup.exe. The Active Directory Federation Services 2.0 Setup Wizard will show up. Advance through the setup wizard accepting the license agreement and choosing the default settings on each screen. When asked for the server role, choose Federation server (the default). 14

15 After running the setup wizard. AD FS is installed correctly on your AD FS server. Step 3: Installing AD FS - Step 3 Apply the October 2011 cumulative update In order to apply the October 2011 cumulative update, run the file _intl_x64_zip.exe you downloaded during the first step. Select a folder of your choosing where to extract the update executable. Then open Windows Explorer, navigate to the extraction folder and run Windows6.1-KB v3-x64.exe. 9.2 Basic configuration of AD FS The basic configuration of AD FS consists of the following steps: 1) Configure a server authentication certificate in IIS 2) Configure Active Directory Federation Services Step 1: Configure a server authentication certificate in IIS The AD FS Setup Wizard has automatically installed an IIS server role on your AD FS server. However, the IIS server does not yet have the correct publishing URL and corresponding SSL certificate configured for your installation of AD FS. In the planning section, you decided on the URL that you will use to publish your AD FS server (AD FS Publishing URL parameter). Note: Once you have chosen a valid server name and public IP address for you AD FS installation, you must register the server name to IP address mapping as a DNS record (CNAME or A and/or AAAA) with a publicly available DNS server. Without this registration, SURFconext will not be able to resolve your AD FS server s IP address from the DNS name. 15

16 Use the procedure below to create a publicly-signed Secure Sockets Layer (SSL) certificate for the name you decided upon above and bind it to the Default Web Site using the IIS Manager console. 1. Open the Internet Information Services (IIS) Manager console: On the Start menu, click All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager. 2. In the console tree, click the root node that contains the name of the computer, and then, in the details pane, double-click the icon named Server Certificates in the IIS grouping. 3. In the Actions pane, click Create Certificate Request. 4. Fill in the Request Certificate form using values that are appropriate for your organization: 5. When asked for a Cryptographic service provider, choose Microsoft RSA SChannel Cryptographic Provider with Bit length

17 Note that it is advised that you choose a bit length of 2048 since the default bit length (1024) is generally considered unsafe as it is expected to be broken within a few years. 6. Type a suitable file name for your certificate request and finish the certificate request wizard. Note the location where you save the certificate request. The default location is c:\windows\system32. You will need to know this location for the next step. 7. Retrieve the certificate request file and submit the request to a public certificate authority of your choice for signing. 8. Import the response of certificate authority by clicking Complete Certificate Request and supplying the file name to the certificate authority s response and a friendly name that you will be able to easily recognize in the management console. 9. In the console tree, click Default Web Site. 10. In the Actions pane, click Bindings. 11. In the Site Bindings dialog box, click Add. 12. In the Add Site Binding dialog box, select https in the Type drop-down list. In the SSL certificate drop-down list, select the certificate you just created. 17

18 Note: If your server has multiple IP addresses, you can configure AD FS to listen to all unassigned IP addresses or to a single IP address by selecting the corresponding value in the IP Address dropdown box. 13. Click OK, and then click Close to finish adding the binding. 14. Close the Internet Information Services (IIS) Manager console. Step 2: Configure the Active Directory Federation Services The final step in basic configuration of the AD FS server is to configure Active Directory Federation Services in stand-alone mode. Note that depending on your organization needs, you might want to consider a different AD FS deployment topology and complete the steps below accordingly. In order to configure the server as a stand-alone federation server, complete the following steps: 1. Open the AD FS 2.0 management console by clicking on All Programs on the Start menu, pointing to Administrative Tools and then clicking on AD FS 2.0 Management 2. Select the AD FS 2.0 node in the left tree view pane and then, in the details pane, click the AD FS Federation Server Configuration Wizard link to start the wizard. 3. On the Welcome page, click Create a new Federation Service, and then click Next. 4. On the Select Stand-Alone or Farm Deployment page, click Stand-alone federation server, and then click Next. 5. On the Specify the Federation Service Name page, verify that the certificate you created before (in step 1) is selected, and then click Next. 6. On the Ready to Apply Settings page, review the settings, and then click Next. 7. On the Configuration Results page, click Close. 8. Leave the AD FS 2.0 management console open, you will need it again in the next chapter. 10 Configuring SURFconext as a trusted claims provider in AD FS Once the basic configuration of AD FS has been applied, the next step is to configure SURFconext as an identifying party. This consists of four steps: 1) Add SURFconext as a Claims Provider to AD FS 2) Edit Claim Rules for the SURFconext Claims Provider 3) Switch to SHA1 signing These steps are detailed below. Unless noted otherwise, all the instructions below are executed on the AD FS server. 18

19 10.1 Add SURFconext as a claims provider to AD FS In order to realize a connection between SURFconext and AD FS, an exchange of metadata is required. SURFconext needs metadata of your AD FS installation in order to accept incoming authentication requests from your installation. Similarly, AD FS needs the SURFconext metadata in order to accept incoming SAML 2.0 tokens from SURFconext. In an ideal case, SURFconext provides the necessary metadata automatically via a downloadable XML file at a fixed URL. Similarly AD FS would provide its metadata to SURFconext automatically via another fixed URL. Exchange of the two metadata URLs would suffice to set up the connection. Unfortunately, the metadata requirements for SURFconext are not compatible with AD FS 2.0. SURFconext assumes compatibility with the following specifications: SAML V2.0 Metadata Interoperability Profile Version Interoperable SAML 2.0 Web Browser SSO Deployment Profile - AD FS does not support these specifications and has several misalignments with them. It provides metadata that is missing several attributes that are required by SURFconext. And SURFconext exposes metadata with attributes that are not accepted by AD FS. Therefore, it is necessary to manually exchange the metadata with SURFconext using the steps below. Setting up Organization and Contact Information Sending metadata URL and additional information to SURFconext Retrieving SURFconext metadata Note: Configuring the metadata manually implies that future changes in metadata are not automatically exchanged. Therefore, whenever the metadata of SURFconext or AD FS changes for example as a result of a configuration change - a manual exchange of the adjusted metadata must be performed to assure correct operation of the connection. Step 1: Setting up Organization and Contact Information SURFconext requires Service Providers to provide a set of metadata. For more information, refer to the SURFconext Technical information for Service Providers: rs Most of SURFconext s metadata requirements can t be added to the metadata that AD FS exposes automatically. The organization and support contact information, however, CAN be configured. This paragraph describes how to add this metadata to your AD FS instance. In order to add the organization and support contact information to your AD FS instance, complete the following steps on the AD FS server: 1. If the AD FS 2.0 management console isn t already opened, open it by clicking on All Programs on the Start menu, pointing to Administrative Tools and then clicking on AD FS 2.0 Management. 19

20 2. Select the AD FS 2.0 node in the left tree view pane, right click the node to open the context menu and select Edit Federation Service Properties from the context menu. 3. In the Federation Services Properties dialog box, switch to the Organization tab. 4. Check the option Publish organization information in federation metadata and provide a suitable Organization display name and Organization URL. 5. Also fill in relevant information into the Support contact information part of the dialog box and click OK when you are finished. Step 2: Sending metadata URL and additional information to SURFconext Now that your metadata is as good as it can possibly be, it is time to contact SURFconext and apply for a connection. In order to connect, you must send an to surfconextbeheer@surfnet.nl and include the following information: 1. The reason you apply for a connection 2. The metadata URL of your AD FS installation. If you set up AD FS as described in this guide, the metadata URL will be where you should replace sts.myinstitute.nl with the AD FS Publishing URL you have chosen while planning the AD FS configuration. 20

21 3. Any additional metadata that is required by SURFconext but is missing in the metadata file that is automatically generated by AD FS. Note: It is possible to manually edit the metadata file that is generated by AD FS. You need to download and save the metadata file from the metadata URL of your AD FS installation. You can then use a text or XML editor to alter or delete existing metadata attributes and add additional attributes as desired. Note also that the metadata file is signed by your AD FS installation with a digital signature. When you change the metadata file, the signature is no longer valid and will not be accepted by SURFconext. To resolve this issue, completely remove the <ds:signature> element with all its content from the metadata file. For additional security, you could use a metadata signing tool to recalculate the signature after applying the changes. Note furthermore that it is not possible to save the altered metadata file back onto the AD FS metadata location. You can publish the metadata file to a different location on your IIS server and send the alternate URL to SURFnet. This allows you to make changes to the metadata later on that are automatically propagated to SURFnet. Alternatively, you could send the metadata file by to SURFnet directly. In this case, however, you would have to send any updated version of the metadata to SURFnet by in the future too, requiring SURFnet to make the adjustments manually, which means a larger turnaround time. 4. The name(s) of any institutes that you would like to provide access to your SharePoint farm to. Note: SURFnet will decide whether to add a connection to your AD FS installation or not and which identity providers will be available to your AD FS installation depending on the request you made. Note furthermore that while SURFnet is adding your AD FS installation to SURFconext, you can continue with the rest of this guide to set up the rest of your configuration. Step 3: Retrieving SURFconext metadata In this chapter, you will use the metadata import capabilities of AD FS to create the SURFconext claims provider trust. In order to do this, you need the metadata for SURFconext. The default metadata is available using the following URL: This metadata includes single-sign-on service location and the public keys that can be used to validate security tokens that SURFconext issues. Note that in addition to this information, SURFconext can provide metadata for specific purposes, e.g. a list of all SURFconext-connected IdP s. that you could use to provide your own home realm selection instead of using the SURFconext where-are-you-from page. Note however that AD FS is out-of-the-box not compatible with this functionality. Specifically, AD FS only supports metadata XML that has a root node of either element type EntityDescriptor, or element type EntitiesDescriptor with exactly one EntityDescriptor child element. SURFconext however returns as many EntityDescriptor elements as there are EngineBlock providers available, so you can t use the metadata XML directly. Instead, you can use the returned metadata to create your own metadata files that are compatible with AD FS by splitting out the EntityDescriptors over multiple metadata files, for example using a splitter tool such as Femma ( Or you can configure your Chaims Provider Trusts manually. For more information, see In this guide, we use the default SURFconext metadata. Perform the following steps to add SURFconext as a Claims Provider to AD FS: 21

22 1. Open the AD FS 2.0 management console by clicking on All Programs on the Start menu, pointing to Administrative Tools and then clicking on AD FS 2.0 Management 2. Select the AD FS 2.0 Trust Relationships Claims Provider Trusts node in the left tree view pane and then, in the Actions pane, click Claims Provider Trusts Add Claims Provider Trust to start the wizard. 3. Click Start to start the wizard. Then select Import data about the claims provider published online or on a local network and type the metadata url for SURFconext into the Federation metadata address textbox. Then click Next to download and parse the metadata file. 4. Specify a Display name that is easy for you to recognize, e.g. SURFconext, and click Next. 22

23 5. Review the settings if you like and press Next. 23

24 6. Leave the checkbox Open the Edit Claim Rules dialog for this claims provider trust when the wizard closes checked and click Close. 24

25 7. After you finish the wizard, an Edit Claim Rules dialog will appear. Leave it open: you will use it further on when setting up claim rules Edit Claim Rules for Claims Provider Trust Now that you have set up the connection with SURFconext, you must configure rules for transforming incoming claims from SURFconext into AD FS intermediate claims. AD FS will transform these intermediate claims into outgoing claims that are sent to SharePoint. You will configure rules for transforming AD FS claims to outgoing claims later on. SharePoint needs a single claim, which is used to uniquely identify the user. This claim must be persistent so that user data such as authorization and object ownership in SharePoint stays mapped correctly. In addition to this identifying claim, other claims can be supplied to SharePoint, for example for defining the user s display name, contact information such as address and mobile phone number, role memberships and other properties or privileges. The following steps guide you through the process of setting up a rule for mapping the incoming nameid claim from SURFconext to an internal claim type in AD FS. You can repeat these steps for other incoming claims you would like to have available within SharePoint. Note however that these additional claims will not be used by SharePoint out-of-the-box. In order to use these additional claims, you will have to implement a custom SPClaimProvider (see: Implementing such a claim provider for SharePoint is out of scope for this guide. 25

26 To configure the claims for inbound receipt, proceed as follow: 1. If you have left the Edit Claims Rules dialog box open after finishing the configuration steps of the previous paragraph, you can skip to step 4. Otherwise, if you have closed the AD FS 2.0 management console, reopen it: on the Start menu, click Administrative Tools, and then click AD FS 2.0 Management. 2. Open the Trust Relationships node in the left pane and then highlight Claims Provider Trusts. 3. In the AD FS 2.0 center pane, right-click SURFconext (or any other name that you supplied in the previous paragraph) and then click the Edit Claim Rules item. 4. On the Acceptance Transform Rules tab, click the Add Rule button. 5. On the Select Rule Template page, select Send Claims Using a Custom Rule, and then click the Next button. 6. On the Configure Rule page, in the Claim rule name box, type Transform incoming nameid into wifcompatiblenameid. 7. In the Custom Rule window, type or copy and paste the following: c:[properties[" == "urn:oasis:names:tc:saml:2.0:nameid-format:unspecified"] => issue(type = " Issuer = c.issuer, OriginalIssuer = c.originalissuer, Value = c.value, ValueType = c.valuetype); 8. Click the Finish button. Note: The specified claim type format is the formal SAML 2.0 format for the name identifier that the SURFconext IdP sends by default. This attribute format is not supported by WIF-based applications like SharePoint 2010, because WIF can only understand claims using URL-style names. That is the reason for transforming the incoming claim attribute into a custom, compatible claim type. This guide uses 26

27 as an example. However, you can use any compatible type name you choose, as long as it is formatted as a URL, not a reserved claim type with a special meaning for SharePoint and as long as you use the same claim type also in the transform rules for the outgoing relying party trust, the trusted identity token issuer and the identity claim type you configure later on. To use your own claim type name, simply replace the bold url in the code above with your own url. Also note that you can send additional claims to SharePoint if you have reason to. SharePoint can consume these claims and use them for group membership, access control, profile information etc. This requires extending the SharePoint framework by writing custom code, however, and is out-of-scope of this guide. Unlike SURFconext, AD FS ignores the format(e.g. urn:oasis:names:tc:saml:2.0:attrname-format:uri) when it reads inbound attributes using default rules. It simply reads the value. Since for this guide, filtering on format is needed, a custom claim rule is used in combination with the claim properties collection, as shown below in the condition part of a rule: c:[properties[ " == "urn:oasis:names:tc:saml:2.0:nameid-format:unspecified "] Switch to SHA1 signing SURFconext uses SHA1 for signing the tokens it issues. AD FS however by default requires at least 256-bit SHA signatures. You therefore must manually configure AD FS to accept SHA1- signed tokens. This can be done on the Advanced tab of the SURFconext Properties dialog box that is shown when you click Properties in the Actions menu of AD FS 2.0 while having the SURFconext claims provider trust selected. Note that this step only needs to be done on the SURFconext Identifying Party configuration. It mustn t be done on the relying party you will configure later on to connect to SharePoint. 27

28 11 Configure SharePoint 2010 as a Relying Party in AD FS In this chapter, AD FS is configured to be the Claims Provider that will issue a claims token that is deduced from the incoming SURFconext token and SharePoint 2010 is the Relying Party that will consume the token it receives from AD FS. To set up the identity federation trust between AD FS and SharePoint 2010, both AD FS and SharePoint 2010 must undergo configuration steps. In AD FS: Configuration of SharePoint as a Relying Party In SharePoint 2010: Configuration of AD FS as a claims provider In which order you configure SharePoint 2010 or AD FS doesn t matter. The federation trust will not be complete until both are configured. In this guide, you begin by creating the relying party in AD FS. We need to configure AD FS with information about our Relying Party. In this case, SharePoint 2010 is our RP it s depending on AD FS to do the authentication and provide the claims. The STS will use this SP to send it claims that are received from the already configured SURFconext IdP. While SAML is used to communicate between the SURFconext IdP and AD FS, WS- Federation is used to communicate between AD FS and SharePoint. From the SharePoint 2010 perspective, we have to configure it to trust the Claims Provider that is sending us claims, and then we have to set up a web application and site that s going to consume those claims. You can choose any URL for publishing your web application. Publishing multiple web applications is also possible. In that case you need multiple URLs, one for each web application. It is also possible to publish one web application under multiple URLs using the zones functionality that is available within SharePoint for this purpose. For each zone, you can define a public URL that this zone will be available from. Also, you can set up authentication settings and authorization policies for each zone separately. Also, you need to set up alternate access mappings for this to function correctly. Detailed discussions of publishing SharePoint web applications under multiple URLs and how SharePoint zones and alternate access mappings work is beyond the scope of this guide. For more information, see Prerequisites and requirements The steps described in the following paragraphs assume that you have completed the previous steps. You should therefore have the following: A working installation with AD FS. The AD FS url is assumed to be and the AD FS identifier is assumed to be the default AD FS identifier: FS/services/trust. Replace these values with your own values, using the AD FS Publishing URL you decided upon. A working installation of SharePoint Foundation. The following url is assumed to be the url of the Central Admin website: where servername is the name of the SharePoint server and port number the number of the TCP/IP port which was chosen randomly by the configuration wizard of WSF. This is the Central Administration URL you have noted down while configuring Sharepoint (8.2). 28

29 11.2 Configure SharePoint 2010 as a new Relying Party Unless noted otherwise, all the instructions below are executed on the AD FS server. To add SharePoint 2010 as a new relying party, proceed as follow: 1. Open the AD FS 2.0 management console. On the Start menu, click Administrative Tools, and then click AD FS 2.0 Management. 2. After the snap-in is loaded, click on the Trust Relationships node, and then highlight Relying Party Trusts. 3. Right-click on Relying Party Trusts and click the Add Relying Party Trust item to start the Relying Party trust wizard. The Add Relying Party Trust Wizard opens. 4. Click the Start button to begin adding the SharePoint 2010 Web application as a Relying Party. 29

30 5. On the Select Data Source page, select Enter data about the Relying party manually, and then click the Next button. 6. On the Specify Display Name page, enter a display name, for example SharePoint and optionally a description for the relying party, for example This is for my SharePoint 2010 SAML claims web application, and then click the Next button. 30

31 7. On the Choose Profile page select AD FS profile and click the Next button. 8. On the Configure Certificate page, you can select a certificate to encrypt the SAML assertion itself. In this guide, no encryption certificate is configured. Click the Next button. Note: Configuring an encryption certificate is not considered necessary in some situations because AD FS will require the connection to SharePoint 2010 be made over SSL/TLS, so the channel the token is sent over is encrypted already. However, the web client is a channel endpoint where the SAML token is available. If you do not want the web client to be able to view the SAML assertion contents as the token is passed from AD FS via your web client to SharePoint, configuring a token encryption certificate is a good option. For debugging purposes, you might want to consider setting up a working configuration first without an encryption certificate, and configuring an encryption certificate only once you have a working setup. This will allow you to view the SAML assertion contents as it is passed from AD FS via your web browser to SharePoint using a web debugging proxy tool like Fiddler ( 31

32 9. Check the box to Enable support for the WS-Fed Passive protocol. For the protocol URL, you need to enter the SharePoint Web Application URL (see planning section), and include the _trust subdirectory. As an example, this guide uses the following URL to the SharePoint 2010 web application: The WS-Fed Passive protocol URL therefore is After entering your URL, click the Next button. Note: This is the URL of the federation services endpoint in the SharePoint 2010 built in STS (SharePoint 2010 WIF integrated) of this Web Application. 10. On the Configure Identifiers page, you need to enter a realm that your Web application will pass to AD FS when users log into the web application. This guide uses the realm urn:sharepoint:portal. 32

33 Note: All identifiers must be unique among relying party configurations, also the identifier must match the realm string value in the SPTrustedIdentityTokenIssuer configuration. The realm is generally created in the format of urn:foo:bar. The realm is associated with a web application and is how AD FS can map the login request that s come in to the relying party trusts it has. When used with SharePoint 2010, AD FS sees the realm associated with the login request, it looks that up to find the relying party trust, and then after it authenticates the user it looks to that WS-Fed Passive protocol URL to know where to redirect the user afterwards. So in this case, we ve entered a realm of urn:sharepoint:portal. When trying to navigate to the SharePoint 2010 site at the user will be redirected to AD FS. This guide will use the realm urn:sharepoint:portal further on when configuring the redirect from SharePoint to AD FS, so the redirect contains this realm for identification of the SharePoint service to AD FS. Once AD FS has authenticated us it will redirect us again to because that s the passive protocol URL for the relying party identified by the trust identifier urn:sharepoint:portal. So, basically, add whatever realm you want to use here and make a note of it because you will need to enter it again when you configure SharePoint Then click the Next button. This guide uses urn:sharepoint:portal as an example. 11. On the Choose Issuance Authorization Rules page, keep the default radio button selected and click the Next button. Note that we assume that you will want all of your users to be able to use this relying party. You could select Deny all users access to this relying party here so you can authorize access users that meet specific criteria by creating corresponding rules later on. 33

34 12. On the Ready to Add Trust page, review trust configuration settings. If you needed to make any other configuration changes at this time to the relying party trust you could do it here. For this scenario we don t need to so just click the Next button to continue. 13. We re done configuring the relying party trust but we still need to create a claim rule to tell AD FS what claims to send back to SharePoint So leave the box checked to Open the Edit Claim Rules dialog for this relying party trust when the wizard closes and click the Close button. 14. After Relying party trust is added, click the Close button to start editing claim mappings for the SharePoint 2010 Web Application Relying Party Edit Claim Rules for Relying Party Trust Now that you have set up the connection with SharePoint, you must configure rules for transforming AD FS intermediate claims into outgoing claims for SharePoint. 34

35 To configure the rules for issuing the outbound claims, proceed as follow: 1. If you have left the Edit Claims Rules dialog box open after finishing the configuration steps of the previous paragraph, you can skip to step 4. Otherwise, if you have closed the AD FS 2.0 management console, reopen it: on the Start menu, click Administrative Tools, and then click AD FS 2.0 Management. 2. Open the Trust Relationships node in the left pane and then highlight Relying Party Trusts. 3. In the AD FS 2.0 center pane, right-click SharePoint (or any other name that you supplied in the previous paragraph) and then click the Edit Claim Rules item. 4. On the Issuance Transform Rules tab, click the Add Rule button. 5. On the Select Rule Template page, select Send Claims Using a Custom Rule, and then click the Next button. 6. On the Configure Rule page, in the Claim rule name box, type Pass through wifcompatiblenameid. 7. In the Custom Rule window, type or copy and paste the following: c:[type == " => issue(claim = c); Note: replace the bold URL in the code above with the URL you used when configuring the claim rules for the SURFconext claims provider trust. Click the Finish button. 35

36 From a configuration standpoint in AD FS, there s nothing else we need to do. However there is one other thing we need to get from it. AD FS uses a certificate to sign the tokens it sends out. This ensures the consumer of the token that it has not been tampered with since it was created. To configure SharePoint 2010 and create a SPTrustedIdentityTokenIssuer in SharePoint, we need a copy of this certificate because we ll use it when configuring it to use AD FS as the trusted identity provider. In the second part of the next chapter, you will transfer this certificate from the AD FS server to the SharePoint server and set up the SPTrustedIdentityTokenIssuer. 12 Configure AD FS as a trusted identifying party in SharePoint Now that AD FS is configured to provide SURFconext tokens to SharePoint, SharePoint must be configured to accept the tokens from AD FS. This consists of two steps: 1) Configuring AD FS as a trusted claims provider 2) Setting up a SharePoint Trusted Identity Provider that is connected to AD FS These steps are detailed below. Step 1: Configuring AD FS as a trusted claims provider SharePoint doesn t trust just any incoming claim tokens. Only signed tokens are accepted, and the certificate that is used to sign the tokens must link back to a root certificate that is in the trusted root certificate store in SharePoint. 36

37 AD FS by default uses a self-signed certificate as a root certificate for alle signing certificates it uses. This self-signed certificate was created by AD FS when it was first set up. In order for SharePoint to accept the AD FS tokens, this self-signed certificate must be exported from AD FS and imported into the SharePoint Trusted Root Certificate store. This can be done via the following steps: 1) On the AD FS Server, open the AD FS 2.0 management console. On the Start menu, click Administrative Tools, and then click AD FS 2.0 Management. After the snap-in is loaded, open the Service node, and select Certificates. 2) In the center Certificates pane, select the CN=ADFS Signing - <your instance name> certificate under the Token-Signing heading. This is the root certificate that AD FS uses to sign child certificates that are used to sign outgoing tokens. Note that for security reasons - AD FS by default doesn t sign tokens directly with the Token-signing certificate that is configured here. Instead, it uses automatic certificate rollover to generate temporary signing certificates that are signed with the root token signing certificate that is configured here. 3) In the Actions pane, click on View Certificate. A Certificate dialog box will appear. 4) On the Certificate dialog box, switch to the Details tab and click on Copy to File. This will open the Certificate Export Wizard. 5) On the Certificate Export Wizard, click Next, leave the default radio button DER encoded binary X.509 (.CER) selected and click Next again, choose a file name for your certificate (e.g. AD FS Signing Certificate) and click Next. 6) Notice the exact location your certificate file will be saved - as you need to copy the file onto the SharePoint server later on - and click Finish. 7) A dialog box confirming the export was succesfull should appear. Click OK to close the dialog box. Now that you have exported the AD FS token signing root certificate, copy the certificate file from your AD FS server onto the SharePoint server. The file can then be deleted from your AD FS server as you will no longer need it there. On the SharePoint server, perform the following steps to import the token signing certificate file into SharePoint as a trusted root certificate: 1. Navigate to the SharePoint 2010 Central Administration site: on the Windows Start Menu, click on SharePoint 2010 Central Administration. 37

38 1) In the center pane, click the Security heading. 38

39 2) Under the General Security heading, click Manage trust. 39

40 3) On the ribbon, click New to add a new trust relationship. 4) In the General Settings section, provide a suitable Name, e.g. <Your Institute> s AD FS server. This name is for your reference only. 5) In the Root Certificate for the trust relationship section, click Browse, select the copied certificate file and click Open. Note: this only works when you use the Internet Explorer for browsing you central administration website. Other web browsers in particular Google Chrome - might have trouble showing the certification file selection dialog. 6) In the Security Token Service (STS) certificate for providing Trust section, leave the Provide Trust Relationship checkbox unchecked and do not fill in any information. Note: Providing Trust Relationship is not necessary in this case as SharePoint will not act as a claims provider to AD FS. Providing Trust Relationships is typically necessary when connecting two SharePoint farms with each other, where claims information is both received from and sent to the other SharePoint farm. 7) Click OK to establish the trust relationship. Note: Don t remove the local trusted service consumer as this will corrupt your SharePoint farm. Step 2: Setting up a SharePoint Trusted Identity Provider that is connected to AD FS Now that the AD FS server is trusted as a token signing service, it is time to configure a trusted identity provider in SharePoint that will act as an endpoint in the communication between SharePoint and AD FS. Perform the following steps to configure this endpoint: 40

41 1. From the Start menu on the SharePoint server, start the SharePoint 2010 Management Shell 2. Type the following commands on the management shell prompt to create the Trusted Identity Provider: $certpath = "c:\share\ad FS.cer" $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath") $map1 = New-SPClaimTypeMapping -IncomingClaimType " - IncomingClaimTypeDisplayName "NameIdentifyer" SameAsIncoming $realm = "urn:sharepoint:portal" $signinurl = $sp = New-SPTrustedIdentityTokenIssuer -Name "sts.myinstitute.nl" -Description "sts.myinstitute.nl" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.inputclaimtype Get-SPTrustedIdentityTokenIssuer Identity "sts.myinstitute.nl" Note that you need to replace the value «c:\share\ad FS.cer» in the script above with the exact full (absolute) path to the certificate file you copied from the AD FS server. If you provide an incorrect path or relative path, you will get the error message: «The system cannot find the file specified.» Note : replace the bold URL name specifying the incoming identifying claim and the bold realm parameter with your own URL and realm name that you chose while configuring AD FS. Note : the signinurl parameter must point to the AD FS endpoint for your relying party. Replace the sts.myinstitute.nl part of the url with the correct url for your situation. Also, replace the sts.myinstitute.nl name, description and identity parameters with the corresponding values for your institute. Note : the commands above do the following : * Create a certificate object using the certificate file provided * Create a mapping from the incoming claim type to the claim type SharePoint uses for identification * Set the parameters realm and singinurl * Create a trusted identity token issuer using the provided certificate, mapping and parameters * Retrieve the trusted identity token issuer that was just created for your reference. 13 Create a claims-aware SharePoint web application Now that SharePoint is set up to trust AD FS, it s time to create a SharePoint Web Application for publishing your SharePoint content. This web application should be claims-aware, so that it can handle incoming claims from SURFconext tokens. In case you have an existing SharePoint web application that you would like to make claims-aware, consult the following information from Microsoft on how to convert your web application to claims-integrated mode: In order to configure your new web application, perform the following steps: 1) Navigate to the SharePoint 2010 Central Administration site: on the Windows Start Menu, click on SharePoint 2010 Central Administration. 41

42 2) In the Application Management list, click on Manage web applications. 42

43 3) Create a new web application by clicking New on the Ribbon. 4) Fill in the following settings in the Create New Web Application form: 1. In the Authentication section, Select the Claims Based Authentication radio button. Classic Mode Authentication is the traditional authentication mode from SharePoint 2007 which doesn t support claims authentication. 2. In the IIS Web Site section, select Create a new IIS web site and give it a suitable name, e.g. sharepoint.myinstitute.nl. Note: You can also leave the Name textbox as-is. If you do so, SharePoint will adjust the textbox automatically to generate a standardized name depending on the values you provide further on. 3. In the Port textbox, type 443, which is the default port for https traffic. Provide a host header that your website will listen to, e.g. sharepoint.myinstitute.nl. And provide a suitable Path where your IIS Web Site will be created: the default path that is supplied by SharePoint is perfectly fine for the purpose of this guide. 43

44 4. Decide whether you would like to allow anonymous access to your web application. When you allow anonymous access, you can allow access to part of your web application to users without logging in. In this guide we choose not to allow anonymous access: in the Security Configuration section, under Allow Anonymous, select the No radio button. 5. In order to make the SharePoint portal available via https only, under Use Secure Sockets Layer (SSL), select Yes. 44

45 Note: SSL is required for secure communication between your client s web browser and AD FS and SharePoint. You therefore must enable SSL in the security configuration section and also install a SSL certificate on the IIS server (see below) with a common name that matches the host header you provided above. Note also that you must register the host header that you provided above in DNS as a CName or A and/or AAAA entry that directs to the SharePoint server. 6. In the Claims Authentication Types section, which appears after you switched from Classic Mode Authentication to Claims Based Authentication above, leave the Enable Windows Authentication and Integrated Windows authentication checkboxes checked. In addition, check the Trusted Identity provider checkbox and the sts.myinstitute.nl trusted identity provider that you added to SharePoint via the script above. Note that by selecting two authentication types, you enable a selector screen in SharePoint where a user can select which authentication type he wishes to use. This is fine for now as it will allow you later to on to log in to the SharePoint site with your computer administrator account and to configure access rights for SURFconext users. In a production setup, you might decide later on to remove the Windows Authentication option to get rid of the selection screen. You can then decide to set up multiple zones for your web application and configure a Windows Authentication on a separate zone for administrative access and to allow for search crawling. All this is out-of-scope of this guide, however. For background information, see: 7. In the Sign In Page URL section, leave the Default Sign In Page radio button selected. This will configure this web application to use the default sign in page you configured when setting up the trusted identity provider. 45

46 8. In the Public URL section, leave the default URL as provided. This setting would allow you to configure a different external URL for your SharePoint site, for example when using a hardware load balancer or reverse proxy server in front of your set-up. 9. In the Application Pool section, leave the Create new application pool radio button selected. Also, there is no need to change the default Application pool name unless you prefer a different name for your reference. Switch the security account for your application pool from Configurable to Predefined and choose Network Service from the dropdown box. Note: In a production environment, you should consider creating a separate service account user in you user store (Active Directory in a multiple server farm or Local SAM for a single server installation) and configuring that user as the security account for your application pool. For background information, see In the remaining sections, leave all the default values. Press the OK button to create the web application. 46

47 11. After a while, you should get a dialog box confirming that the web application has been created. After reading the confirmation details, close the dialog box to finish the creation of the web application. Now that you have created the web application, you need to create a site collection with the initial content at the root of the web application. Use the following steps to create a site collection: 1. In SharePoint 2010 Central Administration, navigate to Application Management using the left navigation pane. 2. Under the Site Collections section in the center pane, click Create site collections. 3. Make sure you select the right web application for which to create a site collection. Click the Web Application selection box, and from the pop-up list of web applications, select the web application you just created in the steps above. 4. In the Title and Description section, type a suitable Title and Description in the corresponding textboxes. 5. In the Web Site Address section, leave the / selected in the URL dropdown box. 6. In the Template Selection section, choose a suitable template for you site collection. Note: The templates that are presented here depend on the version of SharePoint you have installed. In this guide, Windows SharePoint Foundation is installed. Therefore, only basic site templates are available. 7. In the Primary Site Collection Administrator section, type administrator to make your own administrator account site collection administrator. Leave the Secondary Site Collection Administrator section blank for now. 8. In the Quota Template section, leave the No Quota radio button selected. 9. Click OK to create the site collection. 47

48 Note: You will propably get a warning now that your administrator account could not be resolved. The reason for this is that there are multiple accounts that resolve to administrator since there are multiple authentication providers configured. To resolve the conflict, click on administrator in the textbox and choose the local server administrator account from the pop-up list. The local server administrator account can be recognized by the server name followed by a backslash before the administrator part of the account name. Click on OK again to start the creation of the site collection 48

49 Now that you have created a site collection at the root of the web application, there is one thing left to do before your installation is complete: you must create and configure a SSL certificate on the web application you just created. In order to create the SSL certificate, follow the steps that you followed before in paragraph 9.2, step 2 to create a server certificate for AD FS. This time, use your SharePoint web application host header as common name for the certificate. After you have created the certificate, you need to add it to the web site bindings. The following steps guide you through this process: 1. On the Start menu, click Internet Information Services (IIS) Manager to start the IIS management console. 2. In the Connections pane on the left, open the local IIS server node followed by the Sites node within. Then click on your web site node (e.g. sharepoint.myinstitute.nl) to select the web site SharePoint created for your web application. 3. In the Actions menu on the right, click Bindings In the Site Bindings dialog box, choose the default binding that is present already and press Edit. 5. In the Edit Site Binding dialog box, configure the bindings for your web site. Especially, choose the correct SSL certificate to have your site listen to SSL correctly. After configuring the web site bindings correctly, you have completed the set-up of SURFconext for SharePoint! 49

50 14 Testing your set-up Now that you have finished configuring SURFconext for SharePoint, it is time to test your environment. For this purpose, you need a stand-alone client computer with web browser from which you can test the configuration. For several reasons, it is not advised to test your set-up using a web-browser that is running on one of your servers. Doing so might introduce difficulties during testing that look like setup issues, but are in fact artifacts of testing on your local servers. One example of this is the NTLM local machine validation ( but there are several others. Testing from a client computer that is outside your server setup is much neater as this simulates the way end users will experience the set-up. In addition, it allows for easier debugging (using https request sniffing etc., for example). You can test the configuration by navigating to or any other site name you provided during set-up. Once you navigate to the web site, you will be asked whether to sign in using Windows Authentication or SURFconext. Since the only authorized account for your site at this moment is the local administrator account of the SharePoint server, you should choose Windows Authentication now and provide the administrator username and password when asked for. Note: Instead of SURFconext, you will see the name of the trusted identity token issuer you configured in chapter 12, step 2. If you would like to see another name here, change the name of this trusted identity token issuer using PowerShell (get-sptrustedidentitytokenissuer, change Name property, then issue Update command). In order to get rid of the sign in selection screen altogether, disable Windows Authentication on the default zone of your web application as described earlier or have a custom sign-in provider developed. 50