Identity Federation

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 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. SAP assumes this value to be either a user ID, a logon alias, or an entry in the USREXTID table.
`Windows Name`	The name ID is a user ID qualified by a Windows domain.
`X.509 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 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 map the user to their e-mail address in the USREXTID table. 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.

This graphic is explained in the accompanying text.

Account Linking with E-Mail Address

End of the example.

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 interactive federation. Federation is established on the fly. You can enable users to interactively establish federation between existing accounts or even create their own account on the target system with self-registration. 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.

Note Note

Users cannot create their own accounts on the target system with self-registration in AS ABAP.

End of the note.

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.