A.2 Configuring Federation

Federation requires the configuration of a trusted relationship between an identity provider and a service provider. Figure A-2 illustrates setting up federation between two identity servers, because an Access Manager Identity Server can act as either an identity provider or a service provider.

Figure A-2 Configuring Trust Between Site A and Site B

Site A must be configured to trust Site B as a service provider, and Site B must be configured to trust Site A as an identity provider. Until this two-way trust is established, federation cannot occur.

Before setting up a trusted relationship, you must make the following decisions:

Protocol: Identity Server supports SAML 1.1, SAML 2.0, and Liberty. You need to decide which of these protocols to use. If no user interaction is needed, SAML 1.1 is probably a good choice. The SAML 2.0 and Liberty protocols permit user interaction when federating. The user decides whether to federate (link) the accounts and must be logged in at both sites to accomplish this. Liberty offers an additional service, not available with SAML 2.0, that allows the user to select attributes that can be shared with the service provider.

The instructions in Prerequisites for Configuring Federation, use the Liberty protocol. They also indicate how to configure for the SAML 2.0 and SAML 1.1 protocols.

Trust Relationship: You need to decide whether the trusted relationship is going to be from Site A to Site B, from Site B to Site A, or bidirectionally from Site A to Site B and from Site B to Site A. Federation is set up to go from the most secure site to the less secure site. The only time federation is set up to be bidirectional is when both sites are equally secure. The scenario described in Figure A-1 is an example of a trusted relationship that you would want to go only one way, from Site A to Site B, because Site B is not as secure as Site A.

The instructions, starting in Prerequisites for Configuring Federation, explain how to set up the trusted relationship between Site A and Site B. You can easily modify them to set up the bidirectional trust relationships by substituting Site B for Site A (and vice versa) in the instructions and then repeating them for Site B

Attributes to Share: You need to decide whether there are user attributes or roles at Site A that you want to share with Site B. The attributes from Site A can be used to identify the users at Site B. Other attributes might be needed to access protected resources, for example, to satisfy the requirements of an Identity Injection policy.

For all protocols, Sharing Roles explains how to share the roles at Site A with Site B. For the SAML 1.1 protocol, instructions in Prerequisites for Configuring Federation use the LDAP mail attribute to share the user’s e-mail address.

User Identification: You need to decide how assertions can be used to map users from Site A to users at Site B. Identity Server supports four methods:

  • Temporary: This method allows the user access to Site B solely from the credentials of Site A. No effort is made to map the user to a user account at Site B. A temporary account is set up for the user on Site B, and when the user logs out, the account is destroyed.

  • Login: This method requires that the user have login credentials at both Site A and Site B, and when logged in at both sites, the user can select to federate the accounts.

  • Mapped Attributes: This method requires that the sites share attributes and that these attributes are used to create a matching expression that determines whether the user accounts match. For an added security check, the first time the accounts are matched, the user is asked to verify the match by supplying the password for Site B.

    If the match fails, you can allow the federation to fail or you can configure the method to allow the user to use the Login method or the Provisioning method.

  • Provisioning: This method allows the user to create a new, permanent account at Site B.

The configuration instructions in Prerequisites for Configuring Federation use the Login method for the SAML 2.0 and Liberty protocols and Mapped Attributes method for the SAML 1.1 protocol.

The following sections describe setting up a trusted relationship between two Access Manager Identity Servers: