Show TOC

Identity FederationLocate this document in the navigation structure

Use

Identity federation provides the means to share identity information between partners. To share information about a user, partners must be able to identify the user, even though they may use different identifiers for the same user. The SAML 2.0 standard defines the name identifier (name ID) as the means to establish a common identifier. Once the name ID has been established, the user is said to have a federated identity.

The SAML 2.0 standard defines a number of name ID formats. The table below describes the name ID formats.

Name ID Format

Description

E-mail

The name ID is an e-mail address.

Kerberos

The name ID is a Kerberos Principal Name (KPN).

Persistent

The name ID is a permanent opaque string generated by the identity provider for a service provider or an affiliation of service providers.

Transient

The name ID is a temporary opaque string generated by the identity provider for a service provider for the lifetime of a security session.

Unspecified

The implementation of this name ID is vendor-specific. For a trusted service provider on AS JAVA or on AS ABAP, SAP assumes this value to be either a user ID, a logon alias, or other attribute value of the user.

Windows Name

The name ID is a user ID qualified by a Windows domain.

X509 Subject Name

The name ID is the subject name of an X.509 certificate.

Types of Federation

SAML describes the following types of federation:

  • Out-of-band account linking

  • Transient pseudonym identifiers

  • Persistent pseudonym identifiers

Out-of-Band Account Linking

The identities of a user in system A and system B are identified and agreed upon ahead of time between the administrators of the two systems. This kind of agreement is supported by SAML 1.x, too. The administrator of the identity provider and the service provider agree how the name ID used for the user in the identity provider maps to the user in the service provider.

Example

Users in the identity provider always log on with their e-mail address. The logon ID and e-mail address are identical. The administrator of the identity provider agrees to provide the Unspecified name ID format including the logon ID. After a user successfully logs on to the identity provider, whether by Kerberos name or client certificate or whatever, the identity provider provides the logon ID of the user to the service provider in the SAML assertion. The service provider is also configured to use the Unspecified name ID format and is configured to use the user attribute for the e-mail address. The service provider searches for the user with an e-mail address that matches. So long as the e-mail address in the service provider is unique, the service provider can log the user on.

The figure below shows Laurent Becker has different User IDs on the identity provider and service provider. With SAML 2.0 he authenticates on the identity provider. The identity provider passes his user ID to the service provider, and the service provider searches for his user by his e-mail address. Thus his two accounts are linked by user ID and e-mail address.

Figure 1: Account Linking with E-Mail Address

Use this kind of federation to support most scenarios where you need to map user identities across domains.

Transient Pseudonym Identifiers

Federation with transient name IDs creates a federation with a temporary user in the service provider and a permanent user in the identity provider. This federation only exists as long as the security session with the service provider exists. The service provider does not persist data about the visiting user.

User attributes and access rights are generated based on rules applied to attributes sent in SAML messages.

Use this kind of federation when the service provider does not need to record information about users or do not need local user accounts.

Persistent Pseudonym Identifiers

Federation with persistent name IDs establishes a permanent relationship between a user on an identity provider and a user on a service provider or users on an affiliation of service providers. The persistent name ID is used by an identity provider and a service provider as a common name for a single user. If this name ID for a user is the same for multiple service providers, the service providers are said to be affiliated or belong to an affiliation group.

Use this kind of federation to link accounts out-of-band, but without using identifiers that can be traced back to a specific user. This increases the security of your systems by preventing eavesdroppers from determining identities on the basis of name ID formats that pass logon IDs or e-mail addresses. It requires you to establish the pseudonym on both providers ahead of time.

Federation with persistent name IDs also offers the following additional options:

  • Interactive federation

    Federation is established on the fly. You can enable users to interactively establish federation between existing accounts.

    Use this kind of federation if you have not created persistent pseudonyms on the identity provider and service provider ahead of time. It enables you to configure these mappings as you go.

  • Automatic creation

    Federation is established on the basis of attributes passed to the target system. If the user has no account in the target system, the service provider automatically creates the account. The attributes are generated from rules based on SAML 2.0 attributes sent in SAML messages.

    Use this kind of federation to create and even provision users as you federate their accounts on the service provider.

    Note

    The AS ABAP does not support automatic account creation.

Example

The figure below illustrates the accounts of Laurent Becker each have an attribute for a persistent name ID, named opaque ID. The value to use here can be agreed upon in advance by the two system administrators or generated by the identity provider and distributed to the service provider. When Laurent Becker authenticates on the identity provider, the service provider receives the SAML assertion with the opaque ID as the subject. The service provider searches for the user based on the opaque ID and logs the user on.

Figure 2: Account Linking with Persistent Name ID

Securing Data

You can ensure that sensitive data is encrypted when two systems share such information.

The use of the pseudonym name ID formats (transient and persistent) ensure privacy and anonymity between two partners (identity provider and service provider). Neither partner needs to be aware of the local account name used by the other partner, protecting the user's privacy.

More Information