Partager via

AD FS 2.0 Step-by-Step Guide: Federation with CA Federation Manager

  • Article

Applies To: Active Directory Federation Services (AD FS) 2.0

AD FS 2.0 Step-by-Step Guide: Federation with CA Federation Manager

About This Guide

This guide provides step-by-step instructions for configuring a basic identity federation deployment between Microsoft® Active Directory® Federation Services 2.0 (AD FS 2.0) and CA Federation Manager by using the Security Assertion Markup Language (SAML) 2.0 protocol (https://go.microsoft.com/fwlink/?LinkId=193996) with the SAML 2.0 HTTP POST binding.

Terminology Used in This Guide

Throughout this document, there are numerous references to federation concepts that are called by different names in the Microsoft and CA products. The following table assists in drawing parallels between the two vendors’ technologies.

Concept AD FS 2.0 name CA Federation Manager name

XML document sent from the federation party that is managing users to the federation party that is managing an application during an access request describing a user

Security Token

Assertion

Partner in a federation that creates security tokens for users

Claims Provider

Identity Provider

Partner in a federation that consumes security tokens for providing access to applications

Relying Party

Service Provider

Data about users that is sent inside security tokens

Claims

Assertion attributes

In this deployment, each product performs both the claims provider/identity provider role and the relying party/service provider role.

About the Author

Dave Martinez (dave@davemartinez.net) is Principal of Martinez & Associates, a technology consultancy based in Redmond, Washington.

Prerequisites and Requirements

This lab presumes the pre-existence of deployments of AD FS 2.0 and CA Federation Manager as described below.

AD FS 2.0

The test deployment created in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkId=193997) is used as starting point for this lab. That lab uses a single Windows Server® 2008 R2 instance (fsweb.contoso.com) to host both the AD FS 2.0 federation server and a Windows Identity Foundation (WIF) sample application. It presumes the availability of a “Contoso.com” domain in which fsweb.contoso.com is a member server. The same computer can act as the domain controller and federation server in test deployments.

CA Federation Manager

The test deployment created in “Chapter 4: Getting Started with a Simple Partnership” in the CA Federation Manager Guide is used as a starting point for this lab. You can access this document after you install CA Federation Manager. To access this document, click Start, click All Programs, click CA, click FederationManager, click CA Federation Manager Documentation, and then click CA Federation Manager Guide.

The CA Federation Manager test deployment demonstrates federation between two separate instances of CA Federation Manager—idp1.example.com (identity provider) and sp1.demo.com (service provider). Because you have AD FS 2.0 to act as a partner deployment, you only use sp1.demo.com for both the identity provider and service provider functions.

The CA Federation Manager instance at sp1.demo.com is presumed to be deployed in the following way:

Windows

  • Host operating system: Windows Server 2008 R2

  • Database: Microsoft SQL Server® 2005

Note

For the most current information about databases supported by CA Federation Manager, see the CA Federation Manager r12.1 Platform Support Matrix available on the CA Technical Support Site (https://go.microsoft.com/fwlink/?LinkId=194003).

  • Web server role (Internet Information Services (IIS) installed for the federated application

    • Static content role service installed

    • Default website ports: HTTP (8080) and HTTPS (8081)

Important

The default ports 80 and 443 are being used by the embedded Apache Web server in CA Federation Manager. Use these ports to avoid configuration issues. 

  - URL for federation initiation page: https://sp1.demo.com:8080/spsample/testsso.htm  
      
  - URL for target page: https://sp1.demo.com:8080/spsample/welcome.htm

CA Federation Manager

  • Product version: CA Federation Manager r12.1

  • Deployment mode: Standalone

Note

When you use it at the service provider, you can use CA Federation Manager to enable the passing of assertion attributes from inbound federation security tokens to protected applications for use in customization or application-managed access control. The methods available to pass attributes are dependent on the Deployment Mode chosen during installation. Standalone mode uses cookies for passing attributes, while proxy mode adds the ability to use secure HTTP headers. Since this feature is not demonstrated in this guide, you use Standalone mode, the mode recommended for the test deployment in CA documentation.

  • SiteMinder Connector enabled: No

Note

The SiteMinder Connector integrates CA Federation Manager and CA SiteMinder, enabling federated users to access SiteMinder-protected resources without being challenged for credentials. Since its use has no impact on how federation with AD FS 2.0 is configured, it is omitted from the configuration here. During development of this lab, tests using the SiteMinder Connector during cross-vendor federation were successful.

Step 1: Preconfiguration Tasks

Note

All of the actions in this section were performed while logged into Windows with administrative privileges.

Ensure IP Connectivity

Make sure that the CA Federation Manager (sp1.demo.com) and AD FS 2.0 (fsweb.contoso.com) computers have IP connectivity between them. If residing on a separate computer, the Contoso.com domain controller does not require IP connectivity to the CA Federation Manager system.

Configure Name Resolution

Use the hosts file on each computer to configure name resolution of the partner federation servers and sample applications.

Note

We assume that the CA Federation Manager computer is not joined to a domain or otherwise using an external DNS server and that the AD FS 2.0 computer is using the Contoso.com domain controller as its DNS server.

To configure name resolution

  1. Locate the hosts file. The default location in both Windows Server 2003 R2 and Windows Server 2008 R2 is C:\windows\system32\drivers\etc\hosts.

  2. Right-click the file, and then click Open. Select Notepad to open the file.

  3. On sp1.demo.com, add entries for itself and fsweb.contoso.com, for example:

    192.168.1.2 fsweb.contoso.com

    192.168.1.3 sp1.demo.com

  4. On fsweb.contoso.com, add an entry for sp1.demo.com, for example:

    192.168.1.3 sp1.demo.com

  5. Save and close both files.

Verify Clock Synchronization

Federation events typically have a very short Time to Live (TTL). Therefore, ensure that both computers have their clocks synchronized, to avoid errors based on time-outs.

Enable Certificate-based Security

Federation relies heavily on public key infrastructure (PKI) for trustworthy transactions. To use certificates successfully in this lab, you will perform the following prerequisite steps:

  • Install a Microsoft Active Directory Certificate Services stand-alone certification authority (CA) on the CA Federation Manager computer.

  • Import the certification authority’s root certificate to each computer’s Trusted Roots certificate store to enable Windows Internet Explorer® to trust the certificates you will create.

  • Issue separate certificates to enable Secure Sockets Layer (SSL) server authentication on the following Web servers:

    • Apache Web server hosting CA Federation Manager on sp1.demo.com

    • IIS Web server hosting the sample application on sp1.demo.com

    • IIS Web server hosting AD FS 2.0 and the WIF sample application on fsweb.contoso.com

Note

This last certificate replaces the self-signed certificate originally used in the AD FS 2.0 lab.

  • Create a self-signed security token signing private key for use by CA Federation Manager at sp1.demo.com.

Note

On AD FS 2.0, a self-signed token signing certificate was automatically configured during the AD FS 2.0 installation.

Install Active Directory Certificate Services

A CA is required to enable SSL security in CA Federation Manager. Use the following procedure to install Certificate Services onto the CA Federation Manager computer.

To install Certificate Services on fs1.demo.com

  1. To start the Add Roles Wizard, in Server Manager, right-click Roles, and then click Add Roles.

  2. On the Select Server Roles page, select the Active Directory Certificate Services check box.

  3. On the Select Role Services page, select Certification Authority and Certification Authority Web Enrollment.

  4. To allow Server Manager to add IIS capabilities to the installation process, click the Add Required Features button.

  5. On the Specify Setup Type page, select Standalone.

  6. On the Specify CA Type page, select Root CA.

  7. On the Setup Private Key page, select Create a new private key.

  8. On the Configure Cryptography for CA page, leave the default selected (2046 bit, SHA1).

  9. On the Configure CA Name page, in the Common Name for this CA box, type Interop Cert Server.

  10. Complete the wizard without changing all other default values.

  11. Click Close to finish the installation.

Enable SSL for CA Federation Manager

AD FS 2.0 requires SSL connections to federated partners. Use the procedures in this section to enable SSL in CA Federation Manager.

Generate SSL Certificate Requests

CA Federation Manager handles configuration of the embedded Apache Web server through its Web-based interface. The first step to enabling SSL is to generate a certificate request.

To generate a CA Federation Manager SSL certificate request

  1. In the CA Federation Manager interface, click the Infrastructure tab, and then click the SSL Configuration subheading.

  2. In the Embedded Web Server SSL Configuration area, click the Request button next to SSL Configuration Status.

  3. On the Certificate Request page, type the following values.

    Name Value

    Requester name

    sp1.demo.com

    Organization unit

    sp1

    Organization

    demo.com

  4. Click Save, and save the resulting fedmgrsslcertrequest.p10 file to the desktop.

  5. Click the link to return to the SSL Configuration page.

Acquire SSL Certificates and CA Certificate

Use the Certificate Services Web application to acquire the requested SSL certificate as well as the root certificate for the CA, both of which are needed to complete the CA Federation Manager SSL setup process.

To acquire SSL and root CA certificates

  1. From sp1.demo.com, use Internet Explorer to go to the Certificate Services home page at https://sp1.demo.com:8080/certsrv/.

  2. Click the link to request a certificate.

  3. Click the link to submit an advanced certificate request.

  4. Click the link to submit a certificate request by using a PKCS #10 file.

  5. Open the fedmgrsslcertrequest.p10 file in Notepad, and then copy and paste the entire contents into the Saved Request box.

  6. Click Submit.

  7. Click Start, click Administrative Tools, and then click Certification Authority.

  8. Click the Pending Requests folder, and in the left-most pane, right-click the pending request. Click All Tasks, and then click Issue.

  9. In Internet Explorer, to return to the Certificate Services Welcome page, click Home.

  10. Click the link to view the status of a pending certificate request.

  11. Click the saved certificate request, and then click the link to download the certificate.

  12. Save the resulting file to the desktop using the name apachessl.cer.

  13. To return to the Welcome page, click Home.

  14. Click the link to download a CA certificate.

  15. Save the resulting file to the desktop using the name interopca.cer.

  16. Close the Certificate Services Web application.

Import Certificates into CA Federation Manager

Use the CA Federation Manager interface to import the CA certificate and the requested SSL certificate and to enable SSL security on the embedded Apache Web server.

To import the root CA certificate and SSL certificate into CA Federation Manager

  1. In the CA Federation Manager interface, click the Infrastructure tab, and then click the SSL Configuration subheading.

  2. In the Embedded Web Server SSL Configuration area, click the Import button next to the CA certificate box.

  3. Click Browse, and then from the desktop, select interopca.cer. Click Next.

  4. Leave the alias interopca for the certificate. Click Next, and then click Finish.

  5. Click the Browse button next to the Signed Certificate Response box.

  6. Select apachessl.cer, and then click Open.

  7. Click Apply. If successful, a confirmation message appears.

  8. Restart CA Federation Manager for the changes to take effect.

Change System URLs in CA Federation Manager to Use SSL

Now that SSL is available on the CA Federation Manager web server, you need to change the URLs used by CA Federation Manager to use the HTTPS prefix. You do this by changing the global base URL used by CA Federation Manager. Later, you create new federation entities and partnerships by using the new base URL.

To change the base URL in CA Federation Manager

  1. In the CA Federation Manager interface, click the Infrastructure tab, and then click the System Settings subheading.

  2. In the Server Settings area, change the Global Base URL to https://sp1.demo.com.

  3. Click Save.

  4. Restart CA Federation Manager for the changes to take effect.

Enable Certification Authority-based SSL on IIS

The instructions in this section describe how to secure IIS with SSL certificates from the Interop Cert Server. This procedure applies to two instances of IIS—the one running on sp1.demo.com that hosts the CA Federation Manager sample application and the one on fsweb.contoso.com that hosts AD FS 2.0 and the WIF sample application.

Generate a Certificate Request in IIS

Using IIS Manager, generate a certificate request for submission to our certification authority. Later, you will use IIS to process the certificate response you receive.

To generate a certificate request in IIS

  1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  2. In the left-most pane, click the icon with the computer name (FSWEB or SP1), then, in the IIS section of the center pane, double-click Server Certificates.

  3. In the right-most pane under Actions, click Create Certificate Request.

  4. In the Distinguished Name Properties page, type the following values.

    Name Value (sp1.demo.com) Value (fsweb.contoso.com)

    Common name

    sp1.demo.com

    fsweb.contoso.com

    Organization

    sp1

    fsweb

    Organization unit

    demo.com

    contoso

    City/locality

    Redmond

    Redmond

    State/province

    Washington

    Washington

    Country/region

    US

    US

  5. In Cryptographic Service Provider Properties, leave the default values, and then click Next.

  6. In the File Name page, save the file to the desktop using the name iis_ssl.txt, and then click Finish.

Submit the Request and Acquire Certificates

You use the same process used earlier for the Apache SSL certificate request to submit the IIS SSL certificate requests on both computers.

To submit a certificate request and acquire certificates

  1. In Internet Explorer, go to the Certificate Services home page at https://sp1.demo.com:8080/certsrv/.

  2. Click the link to request a certificate.

  3. Click the link to submit an advanced certificate request.

  4. Click the link to submit a certificate request by using a PKCS #10 file.

  5. Open the iis_ssl.txt file in Notepad and copy and then paste the entire contents into the Saved Request box.

  6. Click Submit.

  7. On the certification authority (fs1.demo.com) computer, click Start, click Administrative Tools, and then click Certification Authority.

  8. Click the Pending Requests folder, and in the left-most pane, right-click the pending request. Click All Tasks, and then click Issue.

  9. On the requesting computer, to return to the Certificate Services Welcome page, click Home.

  10. Click the link to view the status of a pending certificate request.

  11. Click the saved certificate request, and then click the link to download the certificate.

  12. Save the resulting file with the name iis_ssl.cer to the desktop.

Note

On the CA Federation Manager computer (sp1.demo.com), proceed to the installation instructions in the following section. Continue from step 13 on the AD FS 2.0 computer (fsweb.contoso.com).

  1. To return to the Welcome page, click Home.

  2. Click the link to download a CA certificate.

  3. Save the resulting file with the name interopca.cer to the desktop.

  4. Close the Certificate Services Web application.

Install Certificates and Apply Them to the IIS Default Web Site

Now you install the certification authority’s root certificate and your newly created SSL certificates into the Windows certificate store. From there, the IIS instances can use the SSL certificate for the Default Web site that contains the sample applications.

Note

On the AD FS 2.0 computer (fsweb.contoso.com), start at step 1. On the CA Federation Manager computer (fs1.demo.com), skip to step 6 since the root certificate was installed in the Windows certificate store by the Certificate Services installation.

To install certificates and apply to the IIS default Web site

  1. Right-click interopca.cer, and to start the Certificate Import Wizard, select Install Certificate.

  2. On the Certificate Store page, click the Place all certificates in the following store.

  3. Click Browse, and then click to show the physical stores.

  4. Select the Local Computer store under Trusted Root Certification Authorities, and click OK.

  5. Click Next, click Finish, and then click OK twice.

  6. In IIS Manager, in the right-most pane under Actions, click Complete Certificate Request.

  7. In the Specify Certificate Authority Response page, navigate to iis_ssl.cer on the desktop. Then, in the Friendly Name box, type iis_ssl, and click OK.

  8. In the Sites folder, in the left-most pane, right-click Default Web Site, and then click Edit Bindings.

  9. On fsweb.contoso.com, select and remove the current binding listed with the HTTPS type listening on port 443. This is the self-signed certificate from the ADFS/WIF lab, which you are replacing.

  10. Click Add.

  11. In the Add Site Binding page, in the Type box, select HTTPS, and in the SSL certificate box, select iis_ssl, and then click OK.

Create the CA Federation Manager Signing Private Key

CA Federation Manager needs a signing private key, because signature processing is currently disabled in the CA Federation Manager demo deployment, but AD FS 2.0 requires digitally signed security tokens. Follow the steps in the procedure to create the private key and import it into CA Federation Manager for later use during federation trust development.

To create the CA Federation Manager signing private key

  1. From inside CA Federation Manager, click the Certs & Keys tab.

  2. Click the Request New Certificate button.

  3. On the Request Certificate page, type the following values.

    Name Value

    Alias

    fedmansign

    Requester name

    demo.com

    Organization unit

    demo.com

    Organization

    demo.com

    Key algorithm

    RSA

    Signature algorithm

    SHA1withRSA

    Key size (bits)

    1024

    Validity period (days)

    1000

  4. Click Save, then save the resulting fedmansign.p10 file to the desktop.

Note

This places a self-signed certificate in the CA Federation Manager certificate list, which is adequate for this lab.
Optionally, you can also submit the fedmansign.p10 file to the Interop Cert Server and generate a certification authority-signed certificate. This is discussed in the Appendix.

Create Sample User

CA Federation Manager maps incoming federated users to a locally residing user store before allowing federated access. This process is called user disambiguation. In this lab, so that AD FS 2.0 users in the Contoso.com domain can gain access to the CA Federation Manager sample application, a local user account must exist in a registered CA Federation Manager user store.

Follow the steps in the procedure to add Alan Shen, a sample user, to the Contoso Active Directory, and to the SQL Server user store used in the CA Federation Manager test deployment at sp1.demo.com.

To add Alan Shen to the Contoso Active Directory

  1. Log in to the Contoso domain controller computer as CONTOSO\administrator.

  2. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.

  3. In the console tree, under Contoso.com, right-click the Users folder. Click New, and then click User.

  4. In the New Object – User page, type the following values, and then click Next.

    Name Value

    First name

    Alan

    Last name

    Shen

    Full name

    Alan Shen

    User logon name

    alansh

  5. Provide a password, clear the User must change password at next logon check box, and then click Next.

  6. Click Finish.

  7. In the right-most pane of Active Directory Users and Computers, right-click the new Alan Shen object, and then click Properties.

  8. On the General tab, in the E-mail box, type alansh@contoso.com, and then click OK.

To add Alan Shen to the CA Federation Manager demo ODBC user store

  1. On the CA Federation Manager computer (sp1.demo.com), click Start, click All Programs, click Microsoft SQL Server, and then click SQL Server Management Studio.

  2. Log on to SQL Server by using the same credentials you used to create the sample user store for the CA Federation Manager demo (typically, the sa account when using SQL Server authentication). The account must have permission to add and modify the user store.

  3. In the Object Explorer page, expand the Databases folder, expand the spdb folder, and then expand the Tables folder.

  4. Right-click the dbo.SmUser folder, and then click Open Table.

  5. Click under the last row in the table and replace the word NULL in each column with the following values.

    Name Value

    UserID

    11

    Name

    alansh

    Password

    siteminder

    LastName

    Shen

    FirstName

    Alan

    EmailAddress

    alansh@contoso.com

    TelephoneNumber

    110

    PIN

    1111

    Mileage

    1234

    PasswordData

    <space>

  6. After entering the last value, press the TAB key. The red exclamation points next to each entered item should disappear, which indicates that the data has been added.

  7. Close SQL Server Management Studio.

Step 2: Configure AD FS 2.0 as the Identity Provider and CA Federation Manager as the Relying Party

In this step, you configure the scenario in which Alan Shen from Contoso (through AD FS 2.0) gets federated access to the demo.com sample application (using CA Federation Manager). The scenario uses the SAML 2.0 POST profile.

Configure CA Federation Manager

Create a New Local Service Provider Entity

Because AD FS 2.0 requires the CA Federation Manager service URLs to be HTTPS, you create a new local SAML2 service provider entity in CA Federation Manager that automatically picks up the new global base URL that you set during preconfiguration.

To create a new local service provider entity

  1. In CA Federation Manager, click the Federation tab, and then click the Entities subheading.

  2. Click the Create Entity button.

  3. On the Select Entity Type page, for Entity Location, select Local. For New Entity Type, select SAML2 SP, and then click Next.

  4. On the Configure Entity page, in the Configure Local SAML2 P Entity section, type the following values.

    Name Value

    Entity ID

    fedman_sp

    Entity name

    fedman_sp

  5. In the Supported Name ID Formats section, select the Select Name ID Formats check box, which selects all formats.

  6. Click Next.

  7. On the Confirm page, verify that all of the service URLs start with https://sp1.demo.com/.

  8. Click Finish.

Create a Remote Identity Provider Entity Using Metadata

Adding a partner using AD FS 2.0 into CA Federation Manager can be done either manually or through metadata import. The AD FS 2.0 metadata file includes information about performing both the identity provider and service provider roles, including the public key which will be used to validate security tokens signed by AD FS 2.0 in the identity provider role.

Note

Creating entities in CA Federation Manager with metadata supplied by AD FS 2.0 requires edits to the AD FS 2.0 metadata XML file, which uses extension points in the SAML 2.0 metadata standard (https://go.microsoft.com/fwlink/?LinkId=194835) that are not supported by CA Federation Manager r12.1.

To create a remote IDP entity using metadata

  1. From the CA Federation Manager computer (fs1.demo.com), using Internet Explorer, go to the AD FS 2.0 metadata XML file at https://fsweb.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml.

  2. Click Page, and then click Save As to save FederationMetadata.xml to the desktop.

  3. Open FederationMetadata.xml with an XML editor.

  4. Delete the sections of the file shown in the following table.

    Description Section starts with… Section ends with…

    Metadata document signature

    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">

    </ds:Signature>

    WS-Trust & WS-Federation application service metadata

    <RoleDescriptor xsi:type="fed:ApplicationServiceType"

    </RoleDescriptor>

    WS-Trust & WS-Federation security token service metadata

    <RoleDescriptor xsi:type="fed:SecurityTokenServiceType"

    </RoleDescriptor>

  5. Save the edited file as FederationMetadata_forFM.xml, keeping it open.

  6. Delete the following section of the file.

    Description Section starts with… Section ends with…

    SAML2 SP metadata

    <SPSSODescriptor WantAssertionsSigned=”true”

    </SPSSODescriptor>

Note

The first two elements of the resulting file should look like:
<EntityDescriptor ID=…>
<IDPSSODescriptor WantAssertionsSigned=”true”…

  1. Save the file to the desktop as FederationMetadata_idp.xml.

  2. In CA Federation Manager, click the Federation tab, and then click the Entities subheading.

  3. Click the Import Metadata button.

  4. On the Select File page, click Browse, and on the desktop, select FederationMetadata_idp.xml. Click Open, and then click Next.

  5. On the Choose Entity page, type adfs_idp in the Entity Name box, and then click Next.

  6. On the Import Certificates page, type the following into the Alias boxes, and then click Next.

    Usage Alias

    Encryption

    adfsencrypt

    Signing

    adfssign

  7. On the Confirm page, confirm the data, and then click Finish.

Create a New Federation Partnership

With the entities in place, now create the CA Federation Manager partnership that ties the two entities together.

To create a new federation partnership

  1. In CA Federation Manager, click the Federation tab, and then click the Partnerships subheading.

  2. Click the Create Partnership button, and then select SAML2 SP -> IDP.

  3. On the Configure Partnership page, in Partnership Name, type ADFS2_to_FM.

  4. In the Local SP list, select fedman_sp.

  5. In the Remote IDP list, select adfs_idp.

  6. In the Available Directories box, select CA FedManager Data Source, and then click the arrow icon to move it into the selected directories box.

  7. Click Next.

  8. On the User Identification page, leave Use Name ID selected as the chosen identity attribute. In the ODBC Search Specification box, type EmailAddress=%s, and then click Next.

Note

This maps the incoming NameID claim value to the EmailAddress field in the SQL Server user store, enabling disambiguation.

  1. On the SSO and SLO page, in the SSO section, select the HTTP-Post check box, and then click Next.

  2. On the Signature and Encryption page, verify that adfssign is listed in the Verification Certificate Alias box, and then click Next.

  3. On the Application Integration page, in the Target box, type https://fs1.demo.com:8081/spsample/welcome.htm, and then click Next.

  4. On the Confirm page, check all values, and click Finish.

Activate the Federation Partnership

CA Federation Manager includes the ability to activate and deactivate partnerships, since only one partnership using a given remote entity ID can be active at a time. A partnership must be active to be in effect.

To activate the federation partnership

  1. In CA Federation Manager, click the Federation tab, and then click the Partnerships subheading.

  2. Click the Actions button next to the ADFS2_to_FM partnership, select Activate, and then click Yes.

  3. If the activation is successful, a confirmation message appears.

Export Service Provider Metadata to a File

You use the metadata export and import capabilities in the two federation products to automate the partner setup process in AD FS 2.0.

To export metadata for local SP entity to a file

  1. In CA Federation Manager, click the Federation tab, and then click the Partnerships subheading.

  2. Click the Actions button next to the ADFS2_to_FM partnership, and then select Export Metadata.

  3. On the Export Metadata page, click Export.

  4. Click Save, leave the default file name fedman_spMetadata.xml, and then save the file to a location where the AD FS 2.0 computer (fsweb.contoso.com) can access it.

  5. Click Close.

Configure AD FS 2.0

Add a Relying Party Using Metadata

Adding a partner by using CA Federation Manager into AD FS 2.0 can be done either manually or through metadata import. In this lab, you use metadata import.

To add a relying party using metadata

  1. In AD FS 2.0, in the console tree, right-click the Relying Party Trusts folder, and then click Add Relying Party Trust to start the Add Relying Party Trust Wizard.

  2. In the Select Data Source page, click Import data about the relying party from a file.

  3. Click Browse, select the fedman_spMetadata.xml file that you created earlier, and then click Open.

  4. Click Next, and to acknowledge the warning about skipped metadata, click OK.

  5. In the Specify Display Name page, type fedman_sp, and then click Next.

  6. In the Choose Issuance Authorization Rules page, leave the default Permit all users to access the relying party selected, and then click Next.

  7. Click Next, and then click Close to complete the wizard and start the Claim Rules editor.

Edit Claim Rules for Relying Party Trust

Claim rules describe how AD FS 2.0 determines what data should reside inside the federation security tokens it generates. The claim rule in this section describes how data from Active Directory is inserted in the security token created for CA Federation Manager.

To edit the claim rules for a relying party trust

  1. The Edit Claim Rules dialog box should already have been opened automatically by the Add Relying Party Trust Wizard.

  2. On the Issuance Transform Rules tab, click Add Rule.

  3. In the Select Rule Template page, leave Send LDAP Attributes as Claims selected, and click Next.

  4. In the Configure Claim Rule page, in the Claim rule name box, type NameID Mapping.

  5. In the Attribute Store list, select Active Directory.

  6. In the Mapping of LDAP attributes section, click the arrow under LDAP Attribute, and then select E-Mail-Addresses.

  7. Click the arrow under Outgoing Claim Type, and then select Name ID.

  8. Click Finish.

Note

When it acts as an identity provider, by default AD FS 2.0 sends the NameID claim without a Name ID format applied. CA Federation Manager understands the AD FS 2.0 default Name ID syntax. Therefore, the lab scenario works with no further action required.

Initiating federated access to a CA Federation Manager-protected application requires the use of a preformatted hyperlink. The hyperlink directs a user to a federation server to get a security token before being redirected to the application. This link can be located either at the account side (for example, on a Contoso employee portal page) or at the resource side (for example, on an unprotected Demo.com site page providing authentication options).

Additionally, regardless of its physical location, the link can direct users to the CA Federation Manager server (which is called RP-initiated or SP-initiated SSO) or the AD FS 2.0 server (which is called IDP-initiated SSO). The syntax of the link changes depending on which model is chosen.

In this lab, you host the link on the demo.com testsso.htm page from the original CA Federation Manager test deployment. You will include both IDP and SP-initiated SSO links.

  1. Open the testsso.htm file in Notepad. Unless you used virtual directories for the initial setup, the likely location is C:\inetpub\wwwroot\spsample\testsso.htm.

  2. Add the following to the end of the document:

    <p>
<a href="https://sp1.demo.com/affwebservices/public/ saml2authnrequest?ProviderID=adfs_idp”> Link to Test SP-initiated POST Single Sign-on to CA Federation Manager from AD FS 2.0 </a>
<p>
<a href="https://fsweb.contoso.com/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=fedman_sp”> Link to Test IDP-initiated POST Single Sign-on to CA Federation Manager from AD FS 2.0</a>

  3. Save and close the file.

Step 3: Test AD FS 2.0 as the Identity Provider and CA Federation Manager as the Relying Party

In this scenario, Alan Shen from Contoso accesses the federated sample application at demo.com.

Note

For the best results, clear all the cookies in Internet Explorer on the AD FS 2.0 computer (fsweb.contoso.com). To clear the cookies, click Tools, click Internet Options, and then click Delete Browsing History.

To access the demo.com application

  1. Log in to fsweb.contoso.com by using the CONTOSO\alansh account.

  2. Open a browser window and navigate to https://sp1.demo.com:8080/spsample/testsso.htm.

  3. Click either of the links to test SSO to CA Federation Manager from AD FS 2.0.

At this point, you should see the demo.com sample application. Review the log files for AD FS 2.0 in Event Viewer and for CA Federation Manager (smtracedefault.log and fwstrace.log) to see the security token information passed between environments.

Note

In this lab, access to the CA Federation Manager–protected application is somewhat controlled because it is limited to users in the local user store identified in the CA Federation Manager partnership. For more robust access control, deploy CA Federation Manager with the SiteMinder Connector.

Step 4: Configure CA Federation Manager as the Identity Provider and AD FS 2.0 as the Relying Party

In this step, you configure a scenario in which a George Curio, a demo.com user (using CA Federation Manager) gets federated access to the WIF sample application through AD FS 2.0. As before, this scenario uses the SAML 2.0 POST profile.

Configure CA Federation Manager

Create a New Local Identity Provider Entity

As before, you need a new local identity provider entity that uses HTTPS service URLs to satisfy AD FS 2.0 requirements. You associate the signing private key that you created for CA Federation Manager during preconfiguration with this entity.

To create a new local identity provider entity

  1. In CA Federation Manager, click the Federation tab, and then click the Entities subheading.

  2. Click the Create Entity button.

  3. On the Select Entity Type page, for Entity Location, select Local. For New Entity Type, select SAML2 IDP, and then click Next.

  4. On the Configure Entity page, type the following values, leaving all other values unchanged.

    Name Value

    Entity ID

    urn:federation:fedman_idp

    Entity name

    fedman_idp

Note

In cases where AD FS 2.0 is the relying party, the claims provider identifier must be a valid Uniform Resource Identifier (URI). This is why the entity ID in this procedure looks different than the entity ID that is used for fedman_sp.

  1. In the Default Signature and Encryption Options section, select the Signing Private Key Alias check box, and then select fedmansign.

  2. In the Supported Name ID Formats and Attributes section, select the Select Name ID Formats check box, which selects all formats.

  3. Click Next.

  4. On the Confirm page, click Finish.

Create a Remote Service Provider Entity Using Metadata

As before, you now use an amended version of the AD FS 2.0 Federationetadata.xml file to create the Contoso remote service provider entity in CA Federation Manager.

To create a remote IDP entity using metadata

  1. From the CA Federation Manager computer (fs1.demo.com), open FederationMetadata_forFM.xml from the desktop using an XML editor.

  2. Delete the following section of the file.

    Description Section starts with… Section ends with…

    SAML2 IDP metadata

    <IDPSSODescriptor WantAssertionsSigned=”true”

    </IDPSSODescriptor>

Note

The first two elements of the resulting file should look like:
<EntityDescriptor ID=…>
<SPSSODescriptor WantAssertionsSigned=”true”…

  1. Save the file to the desktop as FederationMetadata_sp.xml.

  2. In CA Federation Manager, click the Federation tab, and then click the Entities subheading.

  3. Click the Import Metadata button.

  4. On the Select File page, click Browse, and from the desktop, select FederationMetadata_sp.xml. Click Open, and then click Next.

  5. On the Choose Entity page, in the Entity Name box, type adfs_sp, and then click Next.

  6. On the Import Certificates page, leave both certificates selected, and then click Next.

Note

CA Federation Manager does not reimport the certificates since they are already in the key database. It only associates the existing certificates with this new entity.

  1. On the Confirm page, confirm the data, and then click Finish.

Create New Federation Partnership

To create a new federation partnership

  1. In CA Federation Manager, click the Federation tab, and then click the Partnerships subheading.

  2. Click the Create Partnership button, and then select SAML2 IDP -> SP.

  3. On the Configure Partnership page, in Partnership Name, type FM_to_ADFS2.

  4. In the Local IDP list, select fedman_idp.

  5. In the Remote SP list, select adfs_sp.

  6. In the Available Directories box, select CA FedManager Data Source, and then click the arrow icon to move it into the selected directories box.

  7. Click Next.

  8. On the Federation Users page, leave the default settings, and then click Next.

  9. On the Name ID and Attributes page, in the Name ID section, type the following values.

    Name Value

    Name ID format

    Email Address

    Name ID type

    User Attribute

    Value

    EmailAddress

  10. In the Assertion Attributes section, click Add Row, type the following values, and then click Next.

    Name Value

    Assertion attribute

    https://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

    Format

    URI

    Type

    User Attribute

    Value

    FirstName

  11. On the SSO and SLO page, in the SSO section, select the HTTP-Post box, and then click Next.

  12. On the Signature and Encryption page, verify that fedmansign is listed in the box, and then click Next.

  13. On the Confirm page, check all values, and click Finish.

Activate the New Federation Partnership

This is the second partnership that you have created by using the same remote entity ID (https://fsweb.contoso.com/adfs/services/trust). To activate this new partnership, you must deactivate the prior partnership so that CA Federation Manager pulls the proper configuration data during the federation transaction.

To activate the federation partnership

  1. In CA Federation Manager, click the Federation tab, and then click the Partnerships subheading.

  2. Click the Actions button next to the ADFS2_to_FM partnership, select Deactivate, and then click Yes.

  3. Click the Actions button next to the FM_to_ADFS2 partnership, select Activate, and then click Yes.

  4. If successful, a confirmation message appears.

Export Identity Provider Metadata to a File

As before, you use the metadata export and import capabilities in the two federation products to automate the partner setup process in AD FS 2.0.

To export metadata for the local IDP entity to a file

  1. In CA Federation Manager, click the Federation tab, and then click the Partnerships subheading.

  2. Click the Actions button next to the FM_to_ADFS2 partnership, and then select Export Metadata.

  3. On the Export Metadata page, click Export.

  4. Click Save, leave the default file name fedman_idpMetadata.xml, and then save the file to a location where the AD FS 2.0 computer (fsweb.contoso.com) can access it.

  5. Click Close.

Configure AD FS 2.0

Add a Claims Provider Using Metadata

Once again, you use the metadata import capabilities of AD FS 2.0 to create the demo.com claims provider. The metadata includes the public key that is used to validate security tokens signed by CA Federation Manager. Afterward, you must change the default token-signing strength expected by AD FS 2.0 from the CA Federation Manager partner.

To add a claims provider using metadata

  1. In AD FS 2.0, in the console tree, right-click the Claims Provider Trusts folder, and then click Add Claims Provider Trust to start the Add Claims Provider Trust Wizard.

  2. On the Select Data Source page, click the Import data about the claims provider from a file option.

  3. Click Browse, select the fedman_idpMetadata.xml file you created earlier, click Open, and then click Next.

  4. In the Specify Display Name page, type fedman_idp, and then click Next.

  5. Click Next, clear the Open the Edit Claim Rules dialog check box, and then click Close.

To change the expected token-signing strength

  1. In the AD FS 2.0 center pane, right-click fedman_idp, and then click Properties.

  2. On the Advanced tab, in the Secure hash algorithm list, select SHA-1, and then click OK.

Note

CA Federation Manager r12.1 exclusively supports SHA1 as a signing algorithm.

Edit Claim Rules for Claims Provider Trust

The following claim rule describes how data from CA Federation Manager is used in the security token that is sent to the WIF sample application.

To edit the claim rule for fedman_idp

  1. In the AD FS 2.0 center pane, right-click fedman_idp, and then click Edit Claim Rules.

  2. On the Acceptance Transform Rules tab, click Add Rule.

  3. In the Select Rule Template page, select the Pass Through or Filter an Incoming Claim box, and then click Next.

  4. In the Configure Claim Rule page, in the Claim rule name text box, use the following values.

    Name Value

    Claim rule name

    Name ID Rule

    Incoming claim type

    Name ID

    Incoming name ID format

    Email

  5. Select the Pass through only claim values that match a specific email suffix value option. In the Email suffix value box, type mycompany.com, and then click Finish.

  6. Click Add Rule again.

  7. In the Select Rule Template page, select the Pass Through or Filter an Incoming Claim box, and then click Next.

  8. In the Configure Claim Rule page, in the Claim rule name text box, use the following values.

    Name Value

    Claim rule name

    Name Rule

    Incoming claim type

    Given Name

  9. Leave the Pass through all claim values option selected, and then click Finish.

  10. To acknowledge the security warning, click Yes.

  11. Click OK.

Edit Claim Rules for the WIF Sample Application

At this point, incoming claims have been received at AD FS 2.0, but rules that describe what to send to the WIF sample application have not yet been created. You now edit the existing claim rules for the sample application to take into account the new CA Federation Manager external claims provider.

To edit the claim rules for the WIF sample application

  1. In AD FS 2.0, in the left navigation area, click the Relying Party Trusts folder. Then in the center pane, right-click WIF Sample App, and then click Edit Claim Rules.

  2. On the Issuance Transform Rules tab, click Add Rule.

  3. In the Select Rule Template page, select Pass Through or Filter an Incoming Claim, and then click Next.

  4. In the Configure Claim Rule page, type the following values.

    Name Value

    Claim rule name

    Pass Name ID Rule

    Incoming claim type

    Name ID

    Incoming Name ID format

    Email

  5. Leave the Pass through all claim values option selected, and then click Finish.

  6. Click Add Rule again.

  7. In the Select Rule Template page, select Transform an Incoming Claim, and then click Next.

  8. In the Configure Claim Rule page, type the following values.

    Name Value

    Claim rule name

    Transform Name Rule

    Incoming claim type

    Given Name

    Outgoing claim type

    Name

  9. Leave the Pass through all claim values option selected, and then click Finish.

  10. Click OK.

Note

If you configured the optional Step 6: Change Authorization Rules when testing the original AD FS 2.0 with WIF Step-by-Step Guide deployment, ensure that you add back the Permit All Users issuance authorization rules for the WIF sample application before testing this scenario. Or, alternatively, add a new Permit or Deny Users Based on an Incoming Claim rule allowing incoming Name ID = georgec@mycompany.com to access the application.

Step 5: Test CA Federation Manager as the Identity Provider and AD FS 2.0 as the Relying Party

In this scenario, George Curio (georgec) from demo.com accesses the Contoso WIF sample application. To initiate access, as an alternative to using preformatted hyperlinks, we can visit the application directly and leverage a feature in AD FS 2.0 called home realm discovery.

Note

For the best results, clear all the cookies in Internet Explorer on the CA Federation Manager computer (sp1.demo.com). To clear the cookies, click Tools, click Internet Options, and then click Delete Browsing History.

To access the Contoso sample application

  1. On the CA Federation Manager computer, open a browser window and navigate to https://fsweb.contoso.com/ClaimsAwareWebAppWithManagedSTS/default.aspx.

  2. The first page prompts you to select your organization from a list. Select fedman_idp from the list, and then click Continue to Sign In.

Note

This page did not appear in the previous example when you were redirected to AD FS 2.0. That is because at that point there was only one identity provider registered in AD FS 2.0. When only one IDP is available, AD FS 2.0 defaults to forwarding requests to that IDP.

  1. The CA Federation Manager basic logon prompt appears. Log in with the user name georgec and the password siteminder, and then click OK.

At this point, you should see the WIF sample application. Note the presence of the name claim, which was an additional assertion attribute. Also note the nameidentifier claim, which successfully passed the rule limitation of using only addresses with the mycompany.com suffix.

Review the log files for AD FS 2.0 in Event Viewer and for CA Federation Manager (smtracedefault.log and fwstrace.log) to see the security token information that is passed between environments.

Appendix

The purpose of this section is to highlight other possibilities that are outside the scope of this document but are available to architects when they are deploying federation between AD FS 2.0 and CA Federation Manager.

WS-Federation Support

AD FS 2.0 continues to support the WS-Federation protocol for Web-based federation and SSO. CA Federation Manager supports WS-Federation when deployed with CA SiteMinder through the CA SiteMinder Federation Security Services (FSS) add-on technology. Licensing access to the FSS technology is included in the license for CA Federation Manager and vice versa.

For information about how to deploy a test lab between SiteMinder FSS and AD FS using WS-Federation, see the legacy ADFS Step-by-Step Guide: Federation with CA SiteMinder Federation Security Services (https://go.microsoft.com/fwlink/?LinkId=194004).

Certification Authority-issued Token Signing Certificates

For security reasons, production federation deployments require the use of digitally signed security tokens. This lab uses self-signed private key certificates, generated from inside the AD FS 2.0 and CA Federation Manager products, for signing security tokens.

Alternatively, organizations could choose to use a private key certificate issued by a certification authority (CA) for security token signing. The primary benefit of using certificates issued from a CA for token-signing is the ability to check for possible certificate revocation against the certificate revocation list (CRL) from the issuing CA when acting as a relying party or service provider.

In CA Federation Manager, CRL checking is not enabled by default. An administrator can add a CRL checking step through the CA Federation Manager interface. In AD FS 2.0, CRL checking is enabled by default for all claims provider trusts. This has implications in federation deployments between CA Federation Manager (acting as an IDP) and AD FS 2.0 (acting as an RP):

  • If the signing private key used by CA Federation Manager includes a CRL Distribution Point (CDP) extension, that location must be accessible by the AD FS 2.0 Federation Server, or CRL checking fails, resulting in a failed access attempt. CDP extensions are added by default to certificates that are issued by Active Directory Certificate Services in Windows Server 2008 R2.

  • If the signing private key does not include a CDP extension, no CRL checking is performed by AD FS 2.0.

  • You can turn off CRL checking for a specific claims provider trust by using the Windows PowerShell™ command-line and scripting environment. For more information, see the AD FS 2.0 Windows PowerShell Administration section of the AD FS 2.0 Operations Guide (https://go.microsoft.com/fwlink/?LinkId=194005) and the AD FS 2.0 Cmdlets Reference (https://go.microsoft.com/fwlink/?LinkId=177389).

Other Signing and Encryption

The SAML 2.0 protocol enables advanced use of PKI for federation security that is outside the scope of this document. Capabilities include:

  • Digital signing of SAML 2.0 HTTP-artifact profile artifact requests

  • Digital signing of SAML 2.0 logout requests and responses

  • Encryption of SAML 2.0 authnrequests sent by the relying party/service provider to the identity provider

  • Encryption of SAML 2.0 security tokens and assertion data

Non–Name ID Claims in Security Tokens (AD FS 2.0 as IDP)

In this lab, AD FS 2.0 sends only a Name ID claim in the security token that is destined for CA Federation Manager. This is because the lab does not deliver a CA Federation Manager sample application that would facilitate seeing the received claims.

CA Federation Manager provides multiple methods (HTTP headers, cookie variants) for transferring claims in security tokens to protected applications. But to take advantage of this feature, you first must successfully configure CA Federation Manager to read the claims from the AD FS 2.0 token.

While creating a SAML2SP -> IDP partnership in CA Federation Manager, one step is called Application Integration. To properly map AD FS 2.0 claims to CA Federation Manager–protected applications, on this page you:

  • Enable Attribute Mapping

  • Type the name of the expected attribute at the application into the Application Attribute box.

  • Type the Unified Expression Language (UEL) string representative of the claim in the incoming security token into the Assertion Attribute box.

For example, if the application expects a FirstName attribute, and AD FS 2.0 has delivered a Given Name claim in its issued token, the entry in the Application Integration section would be as shown in the following table.

Application attribute Assertion attribute

FirstName

#{attr["https://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"]}

Federated Logout

Both AD FS 2.0 and CA Federation Manager include support for federated single logout. Federated single logout makes it possible for a user to log out completely from their IDP federation server, as well as any replying party applications that are federated through a particular browser session. Federated logout improves security by ensuring that no sessions are left open for misuse, hijacking, or other malicious actions.

SAML 2.0 Artifact Profile

Both AD FS 2.0 and CA Federation Manager support the SAML 2.0 HTTP artifact binding as part of their support for the SAML 2.0 protocol. The artifact profile differs in approach from the HTTP POST profile and may be preferred in some situations.

Alternative Authentication Methods (CA Federation Manager as IDP)

In this lab, when CA Federation Manager acts as the IDP, the user needing a security token authenticates to CA Federation Manager through basic authentication. CA Federation Manager supports other forms of authentication to the federation server, including:

  • Forms-based authentication.

  • SiteMinder Connector. CA Federation Manager provides silent authentication based on the pre-existence of a SiteMinder user session, taking advantage of the authentication methods that are available in SiteMinder, including the Windows authentication scheme.

  • Delegated authentication. CA Federation Manager depends on an external Web access management (WAM) product to perform authentication on its behalf, taking advantage of any of the authentication methods available in that product.

  • CA Federation Manager Agent for Windows Authentication. CA Federation Manager provides silent authentication based on a Windows client’s existing Kerberos or NTLM session, taking advantage of whatever user authentication methods are being used by Windows.

Persistent and Transient Name IDs

Both AD FS 2.0 and CA Federation Manager support the use of persistent and transient Name IDs in SAML 2.0 security tokens. Both types of Name ID use an opaque alphanumeric string to represent a user, instead of a readable and understandable value (such as an e-mail address, which is used in this lab).

A persistent Name ID would use the same alphanumeric value in each request from a given user, while a transient Name ID would change in each browser session. Persistent Name IDs are useful in account-linking scenarios, because they can be appended to an application-side user account and then used like any other attribute for user disambiguation. Transient Name IDs are useful in cases where a user identity is not needed at the application—only confidence that the user successfully authenticated at a trusted relying party—but an ID that tracks back to a specific user is needed for repudiation purposes and similar things.

The following is a summary of the capabilities in this area:

  AD FS as IDP / FM as SP FM as IDP / ADFS as RP

Persistent Name ID / account linking

WORKS

AD FS does not support account linking scenario.

Transient Name ID / pseudo-anonymous access

CA Federation Manager does not support transient Name ID when acting as SP.

WORKS

URLs for Initiating SSO

Both AD FS 2.0 and CA Federation Manager support the use of parameters in hard-coded URLs that initiate the federation process at a federation server that performs either the IDP or the relying party or SP role. CA Federation Manager requires the use of hard-coded links when it acts as an SP. Beyond the parameters used to identify the partner entity, other parameters include:

  • AllowCreate. Allow the creation of persistent or transient identifiers at the identity provider.

  • ProtocolBinding. Identify the required protocol binding (POST, Artifact) for the security token response.

  • RelayState. Indicate the target resource at the service provider.

  • ForceAuthn, IsPassive. Force authentication regardless of the current user session status at the IDP, or force silent authentication relying on an existing session at the IDP.

Note

Not all parameters listed here are supported by both products in all scenarios (IDP-initiated vs. RP-initiated).

Note

For more information about building preformatted hyperlinks directed at CA Federation Manager, please see the section titled “Web Links to Initiate Single Sign-on” in Chapter 8 of the CA Federation Manager Guide.