Configure SAML Channels/Service Providers

This section describes how to create and configure a SAML channel/service provider.

Create a SAML Channel/Service Provider

Prerequisites:  

You have either the metadata file or the URL from the SP Server that you want to add to ActivID Appliance.

For information on the definition and content of metadata, refer to the Oasis technical documentation available at http://www.oasis-open.org

Add a Service Provider Channel

  1. Log on to the ActivID Management Console as an ActivID Administrator.

  2. Select the Configuration tab and, under Policies, select Channels.
  1. Click Add.

  2. Enter the Name and, optionally, a Description, for the channel.

  3. You can either accept the pre-assigned Code to identify the channel, or edit it.

  4. Note: The code is case-sensitive and can be a maximum length of 10 characters and must be unique. The code you specify for the channel cannot be changed once you have created the channel.
  5. From the Type drop-down list, select SAML Service Provider.

  6. Click Next.

The Metadata field and configuration tabs appear.

Import SAML Service Provider Metadata

Important: Uploading incorrect metadata for the ActivID Management Console channel could damage the functioning of the ActivID Management Console. For best practice, do not upload new metadata. Instead, use the metadata already provided for this channel.

You can use one of the following methods to import metadata:

  • Using a file previously exported from the SP:
    1. Click File Import to import the metadata file previously exported from the SP.

    2. Click Browse to locate the file.

    3. Click Upload when the button becomes available.

    4. Click Done.
  • Using a HTTP/HTTPS URL:
    1. Click Http Import.

    2. Enter the URL in the Enter metadata URL field, for example, http://<OpenSSOSP Server Name>:8080/opensso/saml2/jsp/exportmetadata.jsp

    3. Click Upload.
  • Important: If you are using an HTTPS URL, make sure that the application server SSL truststore contains the SP Web Server Root Certificate. If it does not, import the certificate and then restart the application server.

Configure SAML Assertion Settings

  1. Select the Enable assertion encryption option to encrypt the assertions returned to the SP with the SP encryption public key.

  2. Select the Enable OneTimeUse condition option to add the OneTimeUse condition element to the assertion.

This option indicates that the information in the assertion should be used immediately and must not be retained for future use. For example, user attributes contained in the assertion are subject to change from one authentication to the other and should not be cached SP side.

  1. Define the SAML assertion validity period (in minutes) required for the data package to pass in the network between the IdP and the SP. This validity period can be relatively short and configured for each channel.

Configure NameID Format Mapping

Within a SAML assertion, the NameID Policy defines the constraints on the name identifier format to be used to represent the requested subject.

This format can be included as a part of the SAML request or, if it is omitted, it can be any type of format supported by the IdP (as defined in the metadata).

The ActivID IdP supports the following formats:

  • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

  • This format is used to federate an identity through the use of a persistent identifier generated by the ActivID IdP. The persistent identifier (or alias) is constructed using pseudo-random values (having no link with the user’s actual attributes). It is stored as a Federated ID attribute for the user. This format provides permanent privacy since identifiers remain associated with local identities until they are removed. The SP will only know of the persistent identifier that the IdP created for the user visiting the SP. The SP will not know those created for the same user for other SPs.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • This format is similar to the persistent format, except that it corresponds to a one-time-user identifier created at the IdP. It supports anonymity at an SP as it is not associated with a specific local user identity at the SP and is destroyed once the user session terminates.

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

  • This format indicates that the identifier is in the form of an email address.

  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  • The identifier to be used is left to individual implementations.

For each SP channel, it is possible to configure the Email Address and the Unspecified NameID formats so that they are mapped to user attributes.

docnameid

  1. In the Configure NameID section; select the Enable NameID encryption option.

  2. From the nameid-format:unspecified drop-down list, map the User Attribute to be used as an identifier for the subject. The default value is User ID.

  3. From the nameid-format:emailAddress drop-down list, map the Email User Attribute to be used as an identifier for the subject. There is no default value.

docnameid2

Implementation Example:

If the nameid-format:emailAddress is mapped to the user’s E-Mail Address attribute with the user’s email address as user@email.com, then the single-sign-on workflow of a user logging on to the service provider is as follows:

  • User is prompted to enter IdP credentials (for example, username, password).

  • The ActivID IdP generate an assertion with a subject identifier set to user@email.com

  • The SP checks that the email address returned in the assertion corresponds to the identifier of a local account and grant access to the requested resource.

Configure Assertion Encryption Attributes

  • The metadata attribute table is available only when the SP metadata contains an attribute section.

  • The “Add” option to configure such attributes will be available only if the SP metadata file contains extensions with AttributeConsumingService indexes. For more information, see Add Values to be Returned in Assertion.

SAML assertion is always signed by the ActivID IdP. However, when the SP expects encrypted assertions and has been configured as such, you must configure the assertion for encryption.

  1. Import SP metadata in ActivID IdP channel SP.

  1. Under Encryption, select the Assertion option.

  2. This option is available only when the SP Metadata contains the encryption certificate.

  1. Save your settings and then click Next in the channel creation wizard to Select a Trusted Identity Provider (Optional).

Add Values to be Returned in Assertion

An SP might require receiving attribute values within the Response to the authentication Request. The ActivID Appliance allows the configuration of these attributes.

Note: The “Add” option to configure such attributes will be available only if the SP metadata file contains extensions with AttributeConsumingService indexes. See the following example.
AttributeConsumingService index="1">
ServiceName xml:lang="en">OpenSSO service 1</ServiceName>
RequestedAttribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="cn" />
RequestedAttribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="sn" />
RequestedAttribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="street" />
RequestedAttribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="LOA" />
Important: The IdP only returns the configured attribute values within the assertion if the SP SAML Authentication request contains a reference to the index.
  1. Click Add to add values available to be returned in SAML assertion.

  2. From the drop down list, select an assertion attribute

  3. From the drop down list, map the attribute to the value type – Static value, User Attribute, or Predefined Attribute.

  4. From the drop down list, map the attribute to the value (the options vary according to the value type) and click OK.

  5. View the list of values to be returned in SAML assertion:

  6. You can Add or Delete Metadata attributes to be returned as needed.

Select a Trusted Identity Provider (Optional)

When the channel trusts an External Identity Provider that has been configured in the ActivID Appliance, the trusted Identity Provider can be enabled for the channel as described below.

Note: For further information about configuring external identity providers, contact HID Global Technical Support.

  1. From the drop-down list, select Available or All to view the possible trusted IdPs.

  1. Select the check box(es) for the required trusted IdP and click Next to Assign Authorization Profiles Selection Rules (Optional).

Assign Authorization Profiles Selection Rules (Optional)

An Authorization Profile Selection Rule is selected based on the role and Authentication Policy to be used for the user (dynamic authentication) and the roles granted to the user.

Each rule specifies the following conditions to control access:

Note: For push-based authentication via RADIUS, Check Before profiles are not supported (that is, Check Before attributes will not be applied).

  1. Select the Dictionary from the available list (filtered by the type of channel you are creating).

    • The attributes in this dictionary correspond to ActivID Appliance user attributes.
    • Dictionaries are text files of attributes to which you can add entries.
  2. Note: Only Check Before and Send After profiles defined using this dictionary can be selected when defining an Authorization Profile rule.
  3. Click Add to add authorization profiles selection rules.

  4. From the Authentication Policy drop-down list, select the authentication policy that must be enabled for the user’s group.

  5. From the User Role drop-down list, select the role that must be assigned to the user, click Next and proceed to Configure SAML Assertion Settings.

  6. Note: Each condition is independent, so the console does not check if the selected Authentication Policy is eligible for the selected User Role.

Configure the Check Before Rule

  1. Select the Check Before rule option and click Next:

    • No Check Before rule - no checks are performed before the authentication request is processed.
    • Check Before always succeeds - if the user role and authentication policy match those defined in the selection rule, and the provided credentials are valid, the authentication always succeeds.
    • Check Before always fails - if the user role and authentication policy match those defined in the selection rule, the authentication always fails (even if the provided credentials are valid).
    • Use existing Check Before authorization profile - from the drop-down list, select the existing profile.
    • Define new Check Before authorization profile - enter a Name for the new profile. You cannot modify the Dictionary selection.
  2. The subsequent steps depend on the selected option:

Configure the Send After Rule

  1. Select the Send After rule:
    • No Send After rule
    • Use existing Send After Authorization profile - from the drop-down list, select the existing profile.
    • Define new Send After Authorization profile - enter a Name for the new profile. You cannot modify the Dictionary selection.
  2. Note:  
    • If you did not configure a Check Before profile, then you must create/select a Send After profile (that is, the No Send After Authorization profile option is not available).
    • If there are no existing profiles, the Select Send After Authorization profile option is not displayed.
  3. The subsequent steps depend on the selected option:
  4. Either:

    • Click OK to save the selection rule, and then click Close when the success message appears. You return to the Add channel page.
    • Click Back to edit the rule.
  5. Note: You can change the profiles or create a new one, but you cannot edit the attribute selection.
  1. When you have completed the authorization profiles selection rules configuration, click Next to Enable Fallback Authentication (Optional).

Enable Fallback Authentication (Optional)

Select one or both of the Fallback authentications available and click Next:

  1. Click Next and proceed to View the Allowed Authentication Policies.

View the Allowed Authentication Policies

Important: In order to enable the new channel, you must add it to an authentication policy.

The Allowed Authentication Policies tab lists the policies assigned to the channel. As this is a new channel, there are no policies currently assigned when the channel is created.

  1. Click Save to apply the channel settings.

  2. Add this channel to the required authentication policy(ies).

Set the Default Authentication Policy for the SAML Channel

For each security domain, you can define the default authentication policy displayed in the login page for the SAML-based channels (that is, the SAML Service Provider type channels). This includes the ActivID Management Console and ActivID Self-Service Portal.

Note: By default, the authentication policy is User name Password (static password) and the associated GUI templates.
  1. Log on to the ActivID Management Console (for the required domain) and select the Configuration tab.

  1. Under Policies, select Channels.

  1. Click on the Name of the SAML channel for which you want to define the default authentication policy (in this example, the Management Console).

  1. From the Authentication Portal Default Authentication Policy drop-down list, select the required policy.

The list is based on the:

  • Allowed Authentication policies defined for the channel.
  • Authentication Policies Mapping defined for the ActivID Identity Provider.

For example, if you select the AT_LDAP - LDAP Fallback/Passthrough policy, the default authentication method displayed by the ActivID Management Console will be LDAP Username Password.

  1. Click Save.

Configure SAML Channel/Service Provider ActivID Users

The ActivID Appliance users authenticating through a SAML channel (using Single-Sign-On) must have an authenticator record for at least one of the authentication policies allowed for the channel.

For details, see register users and create authenticators.

The following steps explain how to create a customer PKI authenticator and a customer static password authenticator for a registered user.

  1. Search for the required user and select the Wallet tab.

  1. Create the static password by clicking the Create Password link, selecting the Customer Static Password policy and then setting the password.

  1. Create the Customer PKI authentication record by clicking the Register PKI link and then importing the logon PKI certificate from the user’s smart card.

  2. Import the PKI issuer root certificates in the SSL truststore of the application server where the ActivID Authentication Portal is deployed. For further information about importing certificates, see Manage the Keystores and Certificates.

  3. Restart ActivID Appliance.

  4. After you have created the Customer PKI authentication and Customer Static Password authenticator records, you must configure the appropriate Authentication Policies Mappings for this SP channel.