Federated identity is a means of achieving single sign-on, providing user convenience and helping to reduce administrative cost. In Domino® and Notes®, federated identity for user authentication uses the Security Assertion Markup Language (SAML) standard from OASIS.

About this task

SAML authentication allows a user to authenticate once with a designated identity provider (IdP), after which the user can access any server that is partnered with the IdP. Both Notes client and Web client users can make use of SAML-based authentication. Authentication depends upon signed XML identity assertions. The result for the user is transparent authentication and single-sign on with one-time authentication for multiple Domino web servers and applications, as well as any third-party applications that are also partnered with the IdP. The IdP determines the method of the one-time authentication; it might prompt the user for a password, or use a non-password authentication methods such as Integrated Windows™ authentication (SPNEGO/Kerberos) for users within an intranet.

There are three cases in which an organization may use SAML authentication. your organization may need any or all of the configurations.

• For Notes client users on Windows or Citrix, SAML authentication can facilitate a single-sign on solution, usually with the IdP configured for Integrated Windows authentication (IWA). SAML authentication at Notes client startup is referred to as Notes federated login. As a bonus, the HTTP server task does not need to be run on the Domino vault server, because the HTTP portion of SAML is handled within the Notes client.
• For iNotes® client users, SAML authentication also facilitates a single-sign on solution in which the user’s ID file is downloaded from the Notes ID vault. SAML authentication for users of iNotes is referred to as Web federated login. Instructions for configuration of SAML for iNotes clients are on the Notes and Domino Wiki under IBM iNotes Administration Help.
• For users of other applications on Web servers, SAML-based single sign-on is an alternative to another method of single sign-on (SSO) already available in Domino: multi-session server authentication. SAML is most useful when your Domino environment includes third-party Web applications whose services your users access, or if multi-session server authentication is too limiting for your organization -- for example if the target environment requires SSO across DNS domains.

Domino supports both SAML 1.1 and SAML 2.0. The SAML version you use depends partially on your choice of identity provider. SAML 2.0 is recommended unless your organization has a specific reason to use SAML 1.1. SAML 1.1 may be required to support single sign-on with specific applications.

Depending on the level of SAML required for participating applications, the following identity providers that support SAML could serve as the federation for which Domino is the partner:

Table 1. SAML Versions supported by identity providers

Identity Provider (IdP)	SAML Version
IBM Tivoli Access Manager/Tivoli Federated Identity Manager (TAM/TFIM)	SAML 1.1 or SAML 2.0
Microsoft™ Active Directory Federation Services (ADFS)	SAML 2.0 required

Important: SAML authentication includes timestamps. Ensure that the SAML IdP computer and the Domino SAML service provider computer have their clocks synchronized so that these computers share the same notion of current time. If clocks are too far out of sync, a SAML assertion may be rejected because the assertion appears to have an invalid time. This is particularly problematic if the IdP machine time is ahead of the Domino server time, so that Domino rejects an assertion which appears to specify a future time.

For information on NOTES.INI settings that may avoid clock skew, search the Notes and Domino wiki, as well as IBM Support technotes.

Compatibility

The following table lists client configurations with which SAML is not compatible or only partially compatible.

Table 2. Client configurations incompatible with SAML

If your organization uses...	SAML is not recommended because...
Smartcard protected ID	Federated login user IDs cannot be Smartcard protected IDs, because the ID vault required for Notes federated login cannot be used with a Smartcard protected ID.
Notes roaming user whose ID file is stored on the server in a roaming personal address book.	Federated login users cannot be Notes roaming users whose IDs are stored in a roaming personal address book, because the ID vault required for Notes federated login cannot be used with Notes IDs stored in a roaming personal address book.
Notes on a USB device	Federated login cannot be used with Notes on a USB device, because the ID vault required for Notes federated login cannot be used with Notes on a USB device.
Notes user IDs with multiple passwords	Federated login user IDs cannot be Notes user IDs with multiple passwords, because the ID vault required for Notes federated login and cannot be used with IDs that have multiple passwords.
Server-based password checking for Notes users	Disable this feature on server platforms when configuring all Notes users for Notes federated login. Password checking can be enforced for non-federated login users, but cannot be enforced for federated login users.

Procedure

Perform the following tasks.

1. Choosing a federation to configure as your identity provider (IdP)
Federations compatible with Domino include IBM Tivoli Federated Identity Manager (TFIM) and Microsoft Active Directory Federated Services (ADFS). More federation services may eventually be available; check with IBM Support for information.

2. Configuring SAML in Domino
This procedure ensures that an Domino Web server can participate in SAML-based single sign-on (SSO). The Security Assertion Markup Language (SAML) standard allows a Domino server to trust an authentication assertion from a specified identity provider (IdP).

3. Supporting federated login on the Notes client
Federated-identity authentication using the Security Assertion Markup Language (SAML) standard relieves Notes client users of the need to enter a Notes password through the use of Notes federated login. Users' IDs must be stored in an ID vault whose Domino server is configured with host names for identity provider (IdP) partnerships. Notes client users' ID file contents are stored in memory on the client after being downloaded from the ID vault.