Trusted Identity Providers

Dorian: Administrators Guide | Developers Guide | Users Guide | caGrid: Documentation Guides

Overview

Dorian federates users with existing accounts into a Web/Grid services environment.  This allows users to leverage the credentials that they use everyday for things such as email and web applications to authenticate to Web/Grid services.   In order for Dorian to allow a user to a use their existing credentials, the organization issuing the credentials must be registered with Dorian and trusted by Dorian.   Organizations registered with and trusted by Dorian are referred to as Trusted Identity Providers (Trusted IdPs). By default Dorian trusts it's built in identity provider, the Dorian Identity Provider.   Before registering an identity provider with Dorian, each organization must implement and operate an Authentication Service for their identity provider. The Authentication Service provides a standard Web/Grid service interface for authenticating with organizational identity providers in a Web/Grid service environment.   This standard interface is very important when it comes to building applications as it allows applications to authenticate users with any identity provider without needing to know the specifics on how to interact with each type of identity provider.

Once an organization's Authentication Service is operational, the identity provider for the organization can be added to Dorian as a trusted identity provider.  A trusted identity provider consists of the following information:

Name

The name of the organization in which the identity provider represents.

Display Name

The display name of the organization in which the identity provider represents.  This it the name that will be shown to users in user interfaces etc.

Status

Represents the current status of the Identity Provider, Trusted or Suspended.  A Trusted status means that users from that Identity Provider may access the Grid.  A Suspended status means that NO users from that Identity Provider may access the Grid.   The Status attribute allows administrators to quickly isolated an entire identity provider if it were to be compromised.

Account Policy

Each Identity Provider that is registered with Dorian is registered with an account policy which specifies how Dorian should handle accounts from that identity provider.  Each time a user requests a PKI user credential from Dorian, the account policy is applied.  In most cases the account policy determines what happens when the user first authenticates to Dorian, for example should the user be granted immediate access or does their account need to be approved by an administrator.  By default Dorian supports the following account policies:

1. Auto Approval - A new user is automatically registered and given access to the grid. (user's status is active when their account is created).
2. Manual Approval- A new user is automatically registered but not granted access, an administrator is required to grant access. (user's status is pending when their account is created)

Authentication Methods

The SAML Assertions provided by identity providers to Dorian specify how the user authenticated to the identity provider.  Dorian can be configured to specify which authentication mechanims are allowed for each identity provider.   The following is a list of acceptable authentication methods as define by SAML (see SAML 1.1 specification for more details):

1. urn:oasis:names:tc:SAML:1.0:am:password
2. urn:ietf:rfc:1510
3. urn:ietf:rfc:2945
4. urn:oasis:names:tc:SAML:1.0:am:HardwareToken
5. urn:ietf:rfc:2246
6. urn:oasis:names:tc:SAML:1.0:am:X509-PKI
7. urn:oasis:names:tc:SAML:1.0:am:PGP
8. urn:oasis:names:tc:SAML:1.0:am:SPKI
9. urn:oasis:names:tc:SAML:1.0:am:XKMS
10. urn:ietf:rfc:3075
11. urn:oasis:names:tc:SAML:1.0:am:unspecified

Certificate

Dorian leverages SAML to allow a user from a trusted identity provider to use any existing authentication method to obtain PKI credentials from Dorian.   SAML enables Dorian to federated any existing identity management solution into a web/grid services architecture.  Before requesting a PKI user credential the user must authenticate with their identity provider.   If the authentication is successful, the user's identity provider will issue and sign a SAML Assertion proving that they authenticated.    The signed SAML assertion is given to Dorian. Assuming the assertion is signed by a trusted identity provider, Dorian will issue the user a PKI credential.  In order to validate that the SAML Assertion is signed by the user's identity provider, Dorian requires the X.509 certificate that corresponds to the private key that the identity provider used to sign the SAML Assertion.

Authentication Service Information

The Authentication Service provides a standard Web/Grid service interface for authenticating with organizational identity providers in a Web/Grid service environment.   This standard interface is very important when it comes to building applications as it allows applications to authenticate users with any identity provider without needing to know how to interact with each possible identity provider.   Integrating an organization's identity provider into the Grid requires the organization to implement and operate an Authentication Service for their Identity Provider.   Dorian publishes metadata about the identity providers it trusts such that applications can dynamically discover acceptable identity providers.  The result of this is that applications do not need to be reconfigured each time a new identity provider is trusted.  To support this Dorian requires (1) the Service URL for a organization's Authentication Service and (2) the Grid Identity of the Authentication Service.

User Attribute Specifications

Dorian requires SAML assertions provided by Identity Provider's to specify four attributes which are maintained by Dorian for each user, such that Dorian and its administrators may effectively administrate grid user accounts. These attributes include (1) user's local unique user id within the IdP, (2) the user's first name, (3) the user's last name, and (4) the user's email address. In a SAML Assertion attributes are specified with a namespace and name, because the naming of attributes may differ from IdP to IdP, Dorian does not place requirements on how the attributes are named within the SAML Assertion so long as the values of the attributes meet Dorian's formatting requirements. Therefore the namespace and name of each of the four attributes must be specified for each Trusted IdP, such that Dorian knows what to look for when it receives a SAML assertion from the IdP.

Auditing

For security purposes, Dorian maintains the following auditing information for each identity provider:

Trusted Identity Provider Management

• Trusted Identity Provider Search
• Add Identity Provider
• Administrate Identity Provider
• Remove Identity Provider