3.6 Creating a SAML 2.0 Inbound (SAML2 In) Connector Template

To allow the appliance to be a SAML 2.0 service provider, you can create a SAML 2.0 Inbound connector using the Access Connector Toolkit. SAML2 Inbound as an identity source is not available during initialization of the appliance. However, after you export the connector and import it in the appliance, the SAML2 In connector appears as an identity source. You configure an instance of the identity source with information about an appropriate identity provider to enable the service provider functionality of the appliance, and to allow the identity provider to send a SAML token to the appliance using the SAML 2.0 POST profile.

After you configure the SAML2 In identity source, the appliance login page provides a link to the login page of the SAML 2.0 identity provider, located to the left of the user name and password login options. The SAML 2.0 users log in through the identity provider to gain access to the appliance landing page.

3.6.1 Understanding SAML2 In Identity Sources

A SAML2 In identity source can trust assertions from users who log in through the SAML2 In identity provider as known users or unknown users.

When you configure the SAML2 In identity source to accept assertions only for known users, the identity source accepts the authentication for users from the SAML2 In identity provider who have a matching email address in any one of the managed identity sources (for example, eDirectory, Active Directory, or JDBC). Matching will not occur for users created with SSUS. The identity source denies access to the unmatched users. The known users can access applications according to the authorizations you map for their roles (groups) in the managed identity sources. Account provisioning and application access works the same as when the user logs in with corporate credentials through the appliance.

When you configure the SAML2 In identity source to accept assertions only for unknown users, the identity source accepts the authentication for all users from the SAML2 In identity provider, which should be a unique set of users as defined by email addresses. The identity source creates unique user objects in an unmanaged internal identity store for the identity provider. The unknown users can access applications according to the authorizations you map for their roles (groups) in the SAML2 In identity source.

Figure 3-1 Using the Appliance as a Service Provider with the SAML2 In Identity Source

The following is the experience for the SAML2 In user:

  1. The user goes to the appliance login page, then clicks the link for the identity provider.

  2. The user receives the login page from the identity provider, and sends credentials.

  3. The identity provider authenticates the user, then sends a SAML 2.0 assertion via the user’s browser, to the appliance using the SAML 2.0 POST profile. The user identity is based on an email address.

  4. The SAML2 In identity source applies the trust policy that you configured for the identity provider:

    1. Allow access for unknown users: The appliance accepts authentication for all users from the identity provider, and creates a unique user object for the user in an internal identity store, based on the email address in the assertion.

    2. Allow access for known users: The appliance accepts authentication for users who have a matching identity in any of the managed identity sources, based on the email address in the assertion.

  5. The appliance sends the landing page to the authenticated user.

  6. When the user selects an appmark, the appliance builds an assertion for the user identity based on the SAML2 In trust policy:

    • Allow access for unknown users: The user’s identity attributes are based on the user’s information in the SAML2 In unmanaged internal identity store for the identity provider.

    • Allow access for known users: The user’s identity attributes are based on the user’s information in one of the managed identity sources.

  7. The user accesses applications based on the entitlements that are associated with their logged-in identity.

  8. The application service provider establishes a session with the user.

3.6.2 Requirements for Using SAML2 In Identity Sources

Consider the following requirements when you configure a SAML2 In identity source to allow access only for unknown users:

  • The users who authenticate through the SAML2 In identity provider have no identities in the appliance’s managed identity sources. That is, the users in the internal identity store have a unique identity for the appliance based on their email addresses.

  • If a user has an identity in any of the appliance’s managed identity sources, while the user is logged in through their identity provider account, the user cannot access applications based on the entitlements associated with the managed user account.

  • Account provisioning is not supported for the users in the SAML2 In unmanaged internal identity store. Because these users do not have a workforceID, they cannot be provisioned for or access the SaaS applications that depend on the workforceID attribute for authentication, such as Google Apps and Salesforce.

    For more information, see Section 2.4.1, Requirements for Provisioning.

  • Users in a SAML2 In internal identity store are not supported in administration roles for the appliance because their passwords are not stored in the local identity store on the appliance.

3.6.3 SAML2 In Requirements for the Identity Provider

To create a custom SAML 2.0 Inbound connector for an identity provider, ensure that the identity provider meets the following requirements:

  • Supports identity federation using the SAML 2.0 protocol.

    For more information about SAML, see the OASIS website.

  • Supports the SAML web browser single sign-on profile, with the Redirect and POST bindings for service-provider-initiated SSO, and the POST binding for identity-provider-initiated SSO.

  • Provides a capability in the application’s administration console that allows the customer to enable and configure SAML SSO.

    When you configure the SAML2 In connector, the Federation Instructions provide the information that you will need to set up the federation for CloudAccess in the identity provider. This information includes the metadata, a signing certificate for the appliance, the field values to use, and other guidance.

    The SAML 2.0 metadata for the appliance does not contain SAML 2.0 service provider information by default. You must configure at least one instance of a SAML2 In identity source before the appliance publishes service provider information in its metadata. To verify that a SAML2 In identity source is properly configured, open the appliance’s metadata and search for the SPSSODescriptor tag.

    For information about importing and configuring the SAML2 In connector, see Section 3.10, Importing and Configuring Custom Connectors.

  • Provides technical documents that describe SAML federation requirements, metadata, and assertions.

  • Provides an Email attribute for every user. You will map this attribute to the SAML2 In NameID attribute.

    The SAML2 In identity source uses the value mapped to the NameID attribute in an assertion to uniquely identify the user. For more information about the role of email addresses for SAML2 In users, see Section 3.6.2, Requirements for Using SAML2 In Identity Sources.

3.6.4 Planning for a SAML2 In Connector

Before you attempt to create the connector, you must collect information about the originating identity provider. Ask the identity provider vendors the following types of questions to gather the required information:

  • What does your SAML assertion look like?

  • Do you have a SAML metadata document? What fields, if any, are customer-specific?

  • Does your service support the SAML single logout protocol?

  • What are the required configuration steps in your application to set up federation?

  • What is the information that you provide to customers when they are setting up federation?

NOTE:You can use a worksheet to organize the information. See Worksheet for SAML In Custom Connectors.

3.6.5 Creating a SAML2 In Connector for an Identity Provider

A SAML2 In connector template consists of multiple components for federation, metadata, and assertion information.

To create a custom connector template:

  1. Log in as an administrator to the Access Connector Toolkit.

  2. Click New > SAML2 In.

    The connector Type is SAML2 In. The Type Name is Generic SAML2 In Connector.

  3. On the Template tab, complete the following information:

    • Template properties

    • Whether the service provider requires a signing certificate

    • Federation instructions for the service provider

    • New settings that need to be collected on the Configuration page of the connector

  4. Click the Metadata tab, then use one of the following methods to specify the metadata:

    • Select Request, then specify the source URL to retrieve the metadata.

    • Complete the fields to manually generate the metadata.

    • Import the values from a file or URL, and modify them for your deployment environment.

  5. Click the Assertion tab, then define the properties and attributes required for the security token.

    1. On the Properties subtab, specify the properties for the assertion.

    2. On the Attributes subtab, click Predefined, click the identity attribute, modify the definition if needed, then click Save.

      Set NameID to the identity provider attribute that contains the user’s email address.

      If a predefined option does not exist, use New to define it.

    3. (Conditional) If the service provider requires other identity attributes for an assertion, repeat Step 5.b to map the WS-Federation attribute to an attribute in your identity source.

  6. Click Save to save the new connector template.

  7. Proceed to Section 3.9, Exporting a Connector Template to finish creating the new connector.