RapidIdentity Product Guide

Identity Providers and Federation
RapidIdentity Federation Overview

Use RapidIdentity Federation Partners to exchange secure identity information across two or more federated domains. When an application or service is in one network and a user account is in another network, typically the user is prompted for secondary credentials when he or she attempts to access the application or service. These secondary credentials represent the user's identity in the realm where the application or service resides.

Identity federation allows secure identity information exchange across two or more federated domains. Secure exchange requires business agreements between the asserting party sending information and the relying party receiving information. These agreements also require both parties to engage in cryptographic key exchange.

RapidIdentity Federation uses various security realms to perform the mandatory operations to facilitate secure information exchange between requesting and relying parties across different domains. A requestor and the relying party must exchange configuration metadata before beginning to exchange protocol messages that specify unique identifiers to indicate the security realms represented and distinguish them from other possible federation partners and applicable URLs that indicate where protocol messages are to be sent.

Federation Terminology Used in this Guide
  • Attributes: User account information and associated values used to authenticate the users/principals

  • Federation: Identity Federation is the process of delegating an individual's or entity's authentication responsibility to a trusted external party. Each partner in federation plays the role of either an identity provider or a service provider.

  • FQDN (Fully Qualified Domain Name): The complete domain name for a specific computer, or host, on the internet and consists of two parts, the hostname and the domain name.

  • IdP (Identity Provider): Provides attributes to identify and authenticate the end user and sends that data to the service provider along with the user’s access rights for the service to enforce the Service Provider's authentication policies.

  • LDAP (Lightweight Directory Access Protocol): Application protocol for querying and modifying directory services running over TCP/IP. A directory consists of a set of Entries and their attributes, typically organized hierarchically.

  • Relying Party: Relies on authentication and identification services provided by the IdP

  • SAML (Security Assertion Markup Language): Allows identity providers (IdP) to pass authorization credentials to service providers for SSO. SAML is the link between the authentication of a user’s identity and the authorization to use a service.

  • SAML Assertion: The XML document which the Identity Provider sends to the Service Provider that asserts if the user has authenticated successfully. Usually contains attributes about the authenticating user which the Service Provider uses for various identification and authorization purposes.

    • Authentication Assertions: Asserts that the user identified by the assertion successfully authenticated at a particular timestamp and with a particular method.

    • Attribute Assertions: Passes SAML attributes (provides information about the user) to the service provider

  • SP (Service Provider): Requires authentication from the identity provider to grant access rights for a service to the user.

  • SSO (Single Sign-on): Allows users to log in once and those same credentials are reused to log into other service providers.

RapidIdentity Federation contains a joined User and Administrator guide, as the end user is most often a system administrator or otherwise equivalent level technology professional.

RapidIdentity IdP and Portal Sessions

When a user logs into RapidIdentity, they establish both an Identity Provider (IdP) session and a Portal session. The best practice to securely complete user interaction with RapidIdentity dictates that Portal users must log out of Portal and completely close their web browser to terminate a session.

RapidIdentity Federation provides the IdP for federated authentication. The IdP is accessed by Portal for user authentication, and the session timeout is set to 9 hours. Currently, there is not an option to modify the IdP Session timeout.

IdP sessions are invalidated under any of these conditions:

  1. IdP session timeout expires

  2. User logs out of Portal, which redirects to the IdP logout

  3. User logs out of the IdP directly or is redirected to the IdP logout by some other means (e.g., logging out of another federated web application)

  4. User completely closes the web browser

Portal sessions are relevant to browser interactions with RapidIdentity Portal, and are managed by an administrator in the Configuration module. Administrators can kill portal sessions from Configuration > Security > Session Management. Portal session timeouts default to 8 hours, and can be set from Configuration > General > Settings > Authentication.

Note that when a Portal session is closed either manually or through a session timeout, the user loses access to web interaction with Portal. However, while the IdP session remains active, users will not be prompted to re-authenticate when accessing Portal again.

Federation IdP and Federation Partners Configuration
RapidIdentity Federation IdP Setup
RapidIdentity IdP

The RapidIdentity Federation Identity Provider setup requires access to the RapidIdentity Configuration Module. Users must log in to RapidIdentity as a user with the System Administrator or Tenant Administrator role.

  1. From Configuration, click Identity Providers in the Security options.

    configuration_identity.png
  2. idp_pagefed2.png
New Identity Provider Setup

If the Identity Provider has not yet been set up, follow the below steps.

  1. From Identity Providers, select IDP Configuration and click Create New Configuration.

    create_new_idp.png
  2. From the Identity Provider Configuration window enter the following values:

    idp_configuration2.png
    1. Identity Provider Configuration Type*: Automatic/Quick Configuration

    2. Domain*: Enter the IP address of the appliance that will serve as the portal that users will access and that is allocated to the Federation activity.

  3. The Identity Configuration workspace will then be populated with the Identity Provider Configuration data. Click here for more information on Identity Provider configuration data.

    idp_pagefed2.png
  4. From the Configuration menu, click Integration from the Security section.

    systems_integration.png
  5. From the Integration menu, click Federation.

    config_federation.png
    1. Federation Hostname: "localhost'

    2. Federation Username: Enter your domain adminstrator's name

    3. Federation Debug Level: None

    4. Click Update Password.

      1. Enter the Domain Administrator's password.

    5. Click Save.

    Important

    You must select to Trigger Service Reload and Trigger Web Reload to activate the new attributes, or upon logging out, the server configuration will not be saved and future access will fail. An error similiar to this will appear

    SAML_idp_error.png
Validate the Identity Provider Setup

If the Identity Provider setup was performed successfully, you will be able to validate the Adminstrator login in the RapidIdeintity Portal.

Perform these steps using an appliance that has Portal_UI capability.

  1. Log into your Portal using the Domain Administrator account used above in the IdP configuration as the Internal-Appliance Configuration-LDAP.

    image2020-1-22_10-6-21.png
  2. Answer the Setup Security Questions.

    setup_security_qurstions.png
    1. Choose either the Pre-defined or the custom Your Choice questions.

RapidIdentity IdP Configuration

The Identity Provider Configuration page contains various URL sites, links to download metadata and certificate information, the certificate fingerprint, and an option to ensure consistent client addresses. This page provides administrators with their Registered Identity Provider information for user authentication in web applications.

Expand Identity Providers from the Left Menu Items, and click IDP Configuration.

idppage2fed2.png

The current Identity Provider Configuration will be displayed in the workspace. For details, refer to the below table.

Field

Description

Entity ID

The SAML EntityID of the Identity Provider

Base URL

The base URL to the IdP

Logout URL

The IdP's logout URL

Live Metadata URL

The URL to view the metadata associated with the provider which allows the remote vendor to access the metadata at any time.

Metadata

Click to download the registered metadata for the Identity Provider to save as an XML file.

Signing Certificate .PEM File

Click to download the (.PEM) encryption certificate used by the Identity Provider.

Signing Certificate .CER File

Click to download the (.CER) signing certificate used by the Identity Provider.

Certificate Fingerprint

The SHA1 fingerprint of the IdP's signing and encryption certificate

Ensure Consistent Client Address Checkbox

When this box is checked, the client address is maintained across clustering and is bound to a particular client IP address and is only considered valid when used from that same IP address. This box should remain un-checked if the IdP is behind a load-balancer whose own IP address can change over time (e.g. AWS ELB).

The box should be unchecked when users are required to re-authenticate and when an error message occurs stating that a cookie was sent from one address but issued to another address. Sample error message:

[WARN] 2015-09-10 09:24:22.597 RapidIdentity Federation - Client sent a cookie from address xxx.xxx.xxx.xxx but the cookie was issued to address xxx.xxx.xxx.xxx

  • The Delete Configuration function should be used only if there is an issue with the IdP configuration, such as a mismatch of IP address or a change to the DNS name, as the IdP configuration will be deleted and must be reconfigured completely.

    Caution

    Deleting an IdP configuration will also result in deleting all SAML Relying Party configurations and will require reconfiguration of the IdP, Relying Parties, and all federated Service Providers.

Certificate Management

Certificates are created and signed with an expiration date, and Relying Parties use this certificate to establish trust between the Relying Party and the Identity Provider. Once this certificate expires, it will need to be rotated out with a newly generated certificate that is not expired to retain trust with the Relying Parties.

  1. At the bottom of IdP Configuration screen is an option to Rotate certificate now. Click this to generate a new certificate and nullify the old one.

    IDP_Configuration.jpg
  2. A sidebar with a notification will pop up with a note and a checkbox. The Proceed button will not activate until I Understand has been checked.

    Rotate_Certificate_Notice.jpg

    Note

    Doing this is instant, and may cause some authentication failures with SAML integrations. Ensure you update all service providers with the new certificate once it has been rotated.

    Important

    Due to a known issue, a bounce of RapidIdentity Federation servers will be required before the new certificate is fully active.

Federation Partners Overview

Use RapidIdentity Federation Partners to exchange secure identity information across two or more federated domains. When an application or service is in one network and a user account is in another network, typically the user is prompted for secondary credentials when he or she attempts to access the application or service. These secondary credentials represent the user's identity in the realm where the application or service resides.

RapidIdentity Federation uses various security realms to perform the mandatory operations to facilitate secure information exchange between requesting and relying parties across different domains. A requestor and the relying party must exchange configuration metadata before beginning to exchange protocol messages that specify unique identifiers to indicate the security realms represented and distinguish them from other possible federation partners and applicable URLs that indicate where protocol messages are to be sent.

Refer to the following currently supported Federation Partner sections for configuration information.

SAML 2.0 Overview

The overall goal of the SAML SSO Configuration Process is to federate the Customer and Service Provider to provide Customer-environment users a Single Sign-On (SSO) experience to access the Service Provider's web-based service. Users access the web-based service through an Applications icon in the RapidIdentity Portal.This document focuses on configuring a third party application to be authenticated via SAML to the RapidIdentity Portal as an Identity Provider.

SAML 2.0 SSO Settings and Attribute Mapping

The SAML authentication process typically begins when the Identity Provider receives an Authentication Request <AuthnRequest> generated by a SAML Service Provider and conveyed by the authenticating user's web browser. The <AuthnRequest> often indicates where the IdP is to send the SAML Response/Assertion after the authentication completes successfully. Under normal circumstances, the IdP will only honor that requested URL if it is defined as a valid "Assertion Consumer Service" in the Relying Party metadata.

RapidIdentity Federation supports the Oasis SAML V2.0 Enhanced Client or Proxy (ECP) profile. RapidIdentity supports ECP and can be enabled if required by a particular Federation Partner which may require SAML ECP to authenticate and their ECP Advanced Settings, such as Microsoft Office 365™.

The SAML SSO and ECP Advanced Settings are both configured utilizing similar Federation Partners SSO Settings Menu options, therefore, the configuration options are combined below in the SAML SSO / ECP Advanced Settings Table.

  1. Access the SAML SSO Advanced Settings from the Configuration menu and select Federation Partners from the left hand menu items.

    Fed_Partners.png
    1. If there are Federation Partners that have been configured, they will display in the workspace. Hover in the far right of the row and click the Edit button.

      fed_partner_or_add_new.png
    2. If there are no Federation Partners already configured, click Add Federation Partner and select SAML 2.0 from the drop-down to open the configuration settings.

      Add_fed_partner_saml_2_0.png
    3. The Community Federation Partners workspace will load. Refer to the Community section to learn more about that topic.

      Community_SAML_Relying_Parti4es3.png
    4. Click Create SAML Relying Party to open the configuration options.

  2. From the Federation Partners configuration screen, click on SSO Settings.

    sso_adv_settings_saml.png

Note

By default, the ECP Settings are not active. Click Enable ECP Settings to enable ECP Settings. When selecting the Enable ECP Settings checkbox, the ECP Settings section will become available beneath the SSO Settings along with the configuration options.

ECP_Enable.png

When selecting the Enable ECP Settings checkbox, the ECP Settings section will become available beneath the SSO Settings along with the configuration options.

ECP__settings.png
Table 76. SAML SSO and ECP Advanced Settings

Field

Description

Include SAML2 Attribute Statement

If selected the SAML2 SSO or ECP Assertion generated for this Relying Party will contain an <AttributeStatement> element.

SAML2 SSO Assertion Lifetime

Defines the period of time that a SAML2 SSO Assertion generated for this Relying Party will be valid in hours, minutes, and seconds. This setting directly affects the "NotOnOrAfter" attribute in the SAML Assertion which indicates to the Relying Party who receives the Assertion that the Assertion should only be considered valid if it is received before this time instant.

Sign SAML2 SSO or ECP Responses

Determines if the SAML2 SSO or ECP Responses should be cryptographically signed. Choose "Always" to enable signatures on the Response and "Never" to disable signatures on the Response.

Sign SAML2 SSO or ECP Assertions

Determines if the SAML2 SSO or ECP Assertions should be cryptographically signed. Choose "Always" to enable signatures on the Response and "Never" to disable signatures on the Response.

Encrypt SAML2 SSO or ECP Assertions

Determines if the SAML2 SSO or ECP Assertions should be encrypted. Note: this is only possible if the IdP is provided with an "encryption" certificate in the SAML metadata for the Relying Party. Choose "Always" to enable encryption and "Never" to disable encryption.

Encrypt SAML2 SSO or ECP Name IDs

Determines if the Name IDs present in the SAML2 SSO Assertions should be encrypted. Note: this is only possible if the IdP is provided with an "encryption" certificate in the SAML metadata for the Relying Party. Choose "Always" to enable encryption and "Never" to disable encryption.

Signature Algorithm

The algorithm to use when cryptographically signing the SAML2 SSO or ECP Responses and/or SAML2 SSO or ECP Assertions.

SHA-1: Use only when the Relying Party does not support SHA-256.

SHA-256: In general, "SHA-256" should be chosen unless the Relying Party does not support it.

Skip Endpoint Validation When Signed

If the <AuthnRequest> is cryptographically signed and if the IdP can successfully verify that signature by using a public signing key present in the Relying Party's metadata, then the IdP can be instructed to comply with an un-recognized Assertion Consumer Service URL by enabling this option.



Note

After a user authenticates successfully, a SAML Assertion is generated by the IdP. The SAML Assertion contains attributes about the user (e.g. name, email address, etc) and other information describing how and when authentication occurred at the IdP. The SAML Assertion is then embedded inside of a more consolidated generic SAML Response and it is the SAML Response, containing the Assertion, which is ultimately conveyed to the Relying Party.

Attribute Mapping

The SAML Attributes available for assignment will have been set up already under the Federation Partners SAML Attributes section.

  1. Select the Federation Partner from the Federation Partners workspace, and click Edit by hovering in the last column.

    assign_attributes.png
  2. From the Federation Partners window, scroll down to Attribute Mapping.

    attribute_mapping2.png
  3. Click Choose an Attribute to DENY or PERMIT.

  4. Click to expand the drop-down of available attributes to deny or permit mapping.

  5. The Add New Attribute window will load. Select the attribute type from the drop-down.

    select_new_attribute_drop-down_list.png
    1. Based on the type of attribute being added, different menu options will display. Refer to the SAML Attributes section for details on completing the configuration for each attribute type.

  6. Select to Permit or Deny the attribute mapping.

    permit_or_deny_attribute_maping.png
  7. Click Add New Attribute+ to add additional SAML attributes. Repeat steps 2-8.

  8. Click Save to add the attribute to the selected Federation Partner.

    attribute_success.png
    1. A confirmation notice will display if updates are successful.

  9. Click to Trigger Service Reload from the attributes screen and Trigger Web Reload from the Identity Providers screen to activate the new attributes.

SAML Attribute Configuration

SAML Attributes are added during the setup or editing of a SAML Federation Partner and define attributes which may be released to SAML Relying Parties after a user successfully authenticates.

Technology professionals can view the SAML 2.0 technical overview .

The SAML protocol there are several important aspects, the Identity Provider, SAML transactions use Extensible Markup Language (XML) for standardized communications between the identity provider and service providers.

In the SAML protocol, the Identity Provider (IdP) is in charge of authenticating users and if successful, generating a SAML assertion which relays to the Relying Party that the user has successfully authenticated. Often times this information includes when and how they authenticated, and other information about the user required by the Relying Party. This information about the authenticating user is referred to as the attributes of the authenticating user. Common attributes are user's email address and name, but ultimately the Relying Party must communicate which attributes are required from the Identity Provider to release.

  1. From the Configuration menu, select Identity Providers from the Security menu.

    Identity_providers2.png
  2. Expand Identity Providers in the left hand menu items and click Federation Partners.

    Fed_Partners.png
  3. Click Add Federation Partner and select SAML2.0 from the drop-down selector.

    fed_partner_saml2.png
    1. If configuring the SAML Attributes after the Federation Partner has been added, hover and click the edit icon on the far right column of the workspace to select existing attributes.

      saml_edit.png
  4. The current Federation Partners will be displayed in the workspace. Click the SAML Attributes icon in the action buttons at the bottom of the page.

    SAML_Attributes.png

    Note

    The SAML Attributes icon will only display if there are SAML Federation Partners in the system.

  5. The SAML Attributes will load with four separate attribute tabs, LDAP, Static, Name ID, and Static Name ID. Required fields are marked with an asterisk when setting up each attribute.

  6. The first tab is the LDAP Attributes tab. This is where administrators define attributes for values that come directly from LDAP.

    Important

    Administrators define the total pool of attributes which might be allowed to be released to any Relying Party. After the attributes are defined, administrators can choose from the pool which attributes will actually be released to each Relying Party, individually.

    LDAP_Attributes.png
  7. Click the Add LDAP Attribute + button to open the LDAP attribute window.

    create_ldap_attribute.png
    1. LDAP Attribute: The name of the LDAP attribute holding the values which are intended to be released. Each attribute can have one or more values.

    2. SAML Name: The name of the attribute as it will appear in SAML assertions. Different Relying Parties might require the same attribute value, such as a user email address, to be released for them, but could require different names. For example, for a user email address, multiple names such as "EMAIL", "mail", or "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/address."

    3. Friendly Name: This is the name as the LDAP attribute will appear in the SAML Assertion.

    4. Name Format Friendly Name: Select the format value type to be used for the LDAP Attribute Value. SAML Name Formats are typically URIs which convey information to the Relying Party of what format the attribute takes. Depending upon the requirements of the Relying Party, a certain value may or may not be required. This drop-down allows you to choose from some common values or allows you to choose "Custom Name Format" in the event the required value is not one of the provided common values. If the Relying Party does not require a specific value, select "Unspecified."

      name_format_friendly_name.png
      1. Unspecified: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified

      2. URI Reference: urn:oasis:names:tc:SAML:2.0:attrname-format:uri

      3. Basic: urn:oasis:names:tc:SAML:2.0:attrname-format:basic

      4. Custom Name Format: The format value is a free form text field to enter the custom name format.

    5. Name Format Value: The format will adjust based on the Name Format Friendly Name selected

  8. The next tab is the Static tab. Static Attributes are attributes whose values are based on values which generally do not change from user to user. For instance, if a Relying Party wants the IdP to release a common value for all users in a particular organization, then a Static Attribute should be used. When using an LDAP Attribute, then every user in your organization must have the attribute on their LDAP entry containing the same value.

    static_attributes.png
  9. Click the Add Static Attribute + button to open the Create Static Attribute window.

    create_static_id_attribute2.png
    1. Friendly Name: This is the name as the Static attribute will appear in the SAML Assertion.

    2. SAML Name: The name of the attribute as it will appear in SAML assertions. Different Relying Parties might require the same attribute value, such as a user email address, to be released for them, but could require different names. For example, for a user email address, multiple names such as "EMAIL", "mail", or "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/address."

    3. Values: Enter the Static Attribute

      1. Click +Add Another Value to enter multiple acceptable values

    4. Resolvable: Allows the static value to contain tokens which can be resolved to real value(s) at the time the SAML Assertion is being generated.

      1. For example, If two Static attributes exist, first being "givenname" that contains a user's first name and the second "sn" which contains a user's surname, then a third attribute can be generated representing the first two attributes. The Relying Party could request that the Identity Provider release an attribute called "name" containing the surname followed by a comma and space, then by the first name. This could be accomplished with a "Resolvable" static attribute where the value is defined as "%sn%, %givenName%."

    5. Name Format Friendly Name: Select the format value type to be used for the Static Attribute Value. Name ID Formats are typically URIs which convey information to the Relying Party of what format the attribute takes. Depending upon the requirements of the Relying Party, a certain value may or may not be required.

      1. Unspecified: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified

      2. URI Reference: urn:oasis:names:tc:SAML:2.0:attrname-format:uri

      3. Basic: urn:oasis:names:tc:SAML:2.0:attrname-format:basic

      4. Custom Name Format: If the provided common values in the drop-down do not provide the correct format choose "Custom Name Format." If the Relying Party does not require a specific value, select "Unspecified." The format will adjust the Name Format Value.

    6. Name Format Value: This value will adjust based on the Name Format Friendly Name selected.

  10. The next tab is the Name ID Tab. A SAML Assertion may contain 0 or 1 Name ID attribute and 0 or more non-Name ID attributes. Name ID attributes will typically provide information about the format of the value. The Relying Party must specify any requirements that may exist for the Name Format.

    nameid_attributes.png
  11. Click Add Name ID Attribute+. Name ID attributes are typically used to convey the "primary identifying attribute" about the user to the Relying Party. Often times, this will be the user's email address, but ultimately it's up to the Relying Party to communicate what value is expected, if any, and define the format, etc.

    create_name_id_attribute.png
    1. LDAP Attribute: Enter the name of the LDAP Attribute

    2. Name Format Friendly Name: Select the format value type to be used for the Name ID Value. Name ID Formats are typically URIs which convey information to the Relying Party of what format the attribute takes. Depending upon the requirements of the Relying Party, a certain value may or may not be required.

      nameidname_format_friendly_name.png
      1. Unspecified: Allows a free from entry (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)

      2. Email Address: Uses the email format ( (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)

      3. X.509 Subject Name: Uses the subject name of the X509 Certificate (urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName)

      4. Windows Domain Qualified Name: Uses the FQDN of the hostname and domain name (urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName)

      5. Kerberos Principal Name: Uses the Principal Name to identify the user or service (urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos)

      6. Entity Identifier: Uses a URI is a URL that contains the domain name of the entity (urn:oasis:names:tc:SAML:2.0:nameid-format:entity)

      7. Persistent Identifier: Reliably points to a digital entity as an identifier to build trusted connections (Directsurn:oasis:names:tc:SAML:2.0:nameid-format:persistent)

      8. Transient Identifier: An identifier intended to be used for a single session only (urn:oasis:names:tc:SAML:2.0:nameid-format:transient)

      9. Custom Name Format: The drop-down contains some common Name Format values, but if the required value is not present in the list of available values, choose the Custom Name Format option and provide a custom value. If the Relying Party does not require a specific value, select "Unspecified. "The format will adjust the Name Format Value.

    3. Name Format Value: This value will adjust based on the Name Format Friendly Name selected.

  12. The last tab is the Static Name ID tab. Static Name ID Attributes are like Static Attributes, except they define the value of the Name ID Attribute in the SAML Assertion.

    static_name_id_attributes.png
  13. Click Add Static Name ID Attribute+.

    create_static_id_attribute.png
    1. Values: Enter a Name ID Attribute

      1. Click +Add Another Value to enter multiple acceptable values

    2. Resolvable: Allows the static value to contain tokens which can be resolved to real value(s) at the time the SAML Assertion is being generated.

      1. For example, If two Static attributes exist, first being "givenname" that contains a user's first name and the second "sn" which contains a user's surname, then a third attribute can be generated representing the first two attributes. The Relying Party could request that the Identity Provider release an attribute called "name" containing the surname followed by a comma and space, then by the first name. This could be accomplished with a "Resolvable" static attribute where the value is defined as "%sn%, %givenName%."

    3. Name Format Friendly Name: Select the format value type to be used for the Static Name ID Value. SAML, Static Name ID Formats are typically URIs which convey information to the Relying Party of what format the attribute takes. Depending upon the requirements of the Relying Party, a certain value may or may not be required.

      nameidname_format_friendly_name.png
      1. Unspecified: Allows a free from entry (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)

      2. Email Address: Uses the email format (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)

      3. X.509 Subject Name: Uses the subject name of the X509 Certificate (urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName)

      4. Windows Domain Qualified Name: Uses the FQDN of the hostname and domain name (urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName)

      5. Kerberos Principal Name: Uses the Principal Name to identify the user or service (urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos)

      6. Entity Identifier: Uses a URI is a URL that contains the domain name of the entity (urn:oasis:names:tc:SAML:2.0:nameid-format:entity)

      7. Persistent Identifier: Reliably points to a digital entity as an identifier to build trusted connections (Directsurn:oasis:names:tc:SAML:2.0:nameid-format:persistent)

      8. Custom Name Format: If the provided common values in the drop-down do not provide the correct format choose "Custom Name Format". If the Relying Party does not require a specific value, select "Unspecified."The format will adjust the Name Format Value.

    4. Name Format Value: This value will adjust and populate based on the Name Format Friendly Name selected.

SAML Relying Party Authentication Configuration Examples

There are a variety of web-based applications that support a SAML-based Single Sign-On service to configure your Identity Provider (IdP) server connection. In the information provided in the link above, the third-party identity provider is Identity Automation through RapidIdentity Federation.

This guide provides steps to configure the following SAML Relying Parties with RapidIdentity:

Follow the steps in each section above to configure SAML authentication for the appropriate web-based application.

Sample RapidIdentity SAML Integrations

Identity Automation supports SAML authentication for numerous web-based applications. For example, Google Apps and Salesforce SAML authentication configurations are examples, and are not required for all RapidIdentity Federation deployments. The Identity Automation Federation guides detail SAML integration, where available, on an application-specific basis.

RapidIdentity Community SAML Relying Party Configuration - New UI

Google supports a SAML-based Single Sign-On service for its web-based application to configure your Identity Provider (IdP) server connection. In the information provided in the link above, the third party identity provider is Identity Automation through RapidIdentity Federation.

The RapidIdentity Community provides preconfigured SAML Relying Parties to supported web-based applications to simplify the IdP server connection. Importing from the Community preconfigures required relying party data for the IdP.

Follow these steps to configure a SAML Relying Party authentication configuration using the Community.

Note

Third party SAML Relying Parties may update their setup sequence without notification, therefore, the steps below may vary slightly.

  1. From the RapidIdentity Configuration Module, select Identity Providers from the Security menu.

    configuration_identity.png
  2. The Identity Provider Configuration workspace will launch. Select Federation Partners from the Identity Providers left menu items. From the Add Federation Partner drop-down button, select SAML 2.0.

    fed_partner_saml2.png
  3. The Community-SAML Relying Parties workspace will launch.

    Community_SAML_Relying_Parti4es4.png
    1. The Community contains basic configuration for commonly used SAML Relying Parties. Before manually adding a new SAML Relying Party, search the Community for the entry. The Community will be updated on an ongoing basis with new SAML Relying Parties.

    Tip

    The Community provides some general information about the available preconfigured SAML Relying Parties. Community entries can be created by individual users or by RapidIdentity. Click Federation Partners in the path "Federation Partners>Community>SAML Relying Parties" to return to the main Federation Partners page.

    Community_SAML_menu.png
    • Check Marks:

      • Green = Verified (RapidIdentity Administrators have validated operability.)

      • Grey = Unverified (RapidIdentity Administrators have not validated operability.)

    • Headphones:

      • Green = Supported (Contact RapidIdentity Support for questions or issues.)

      • Grey = Unsupported (RapidIdentity Support is not available for questions or issues.)

  4. Hover over an entry in the Community - SAML Relying Parties workspace and click Import.

    Community_SAML_Relying_Parti4es2.png
  5. A confirmation message will appear and the imported SAML Relying Parties will be imported into the Federation Partners workspace and will display.

    fed_partner_added_2.png

    All information to register the SAML Relying Party will automatically be configured. Click Edit next to the SAML Relying Party to view the details.

    registered_saml_community2.png
Salesforce SAML Integration Guide - New UI

Salesforce supports SAML Single Sign-on and provides a SAML Single Sign-on overview with a Single Sign-on Implementation Guide.

Fortunately, within RapidIdentity Federation, Salesforce SAML authentication configuration is very similar to G Suite SAML authentication configuration.

The preliminary Salesforce SAML authentication configuration steps require that both RapidIdentity Portal and RapidIdentity Federation (IdP) are internet accessible and are configured as described in the provided links. In this topic, the IdP is the Identity Provider which is the system that is logged into using credentials, which is RapidIdentity. The Service Provider (SP) is the system that automatically receives the credentials for login, which is Salesforce, in this case.

Follow these steps to configure Salesforce SAML Authentication.

  1. From the RapidIdentity Configuration Module, select Identity Providers from the Security menu.

    Identity_providers2.png
  2. The Identity Provider Configuration workspace will launch. The following RapidIdentity fields will be mapped into Salesforce as shown below:

    • Entity ID = Issuer = https://saml.salesforce.com

    • Entity ID + /profile/SAML2/POST/SSO = Identity Provider Login URL

    • Logout URL = Identity Provider Logout URL

    Table 77. Salesforce Fields' URL Values

    Field Name

    URL

    Issuer

    Enter your identity provider URL, such as https://company.net/idp

    Identity Provider Login

    Enter your identity provider login URL, such as https://company.net/idp/profile/SAML2/POST/SSO

    Identity Provider Logout

    Enter your identity provider logout URL, such as https://company.net/idp/logout

    Entity ID

    Enter the Salesforce SAML URL, such as https://saml.salesforce.com



  3. Select which format of the certificate to download, either a .PEM or a .CER file and click the download link to the signing/encryption certificate used by the Identity Provider.

    idp_certificate_download2.png
  4. Log in to the service provider, Salesforce, as an administrator.

  5. Navigate to the Setup Gear, and select Setup.

    sf_settings.png
  6. Search in Setup for Single Sign-On Settings.

    sf_sso_settings.png
  7. Click New and fill out the form using the data from Step 2, including the Certificate.

    sf_data_form.png
  8. Click Save.

  9. Navigate to Security Controls | Single Sign-on Settings.

  10. Click on the Name of the SSO (IdAuto_IDP).

    sf_copy_name.png
  11. Click Download Metadata.

    download_metadata.png
  12. Return to the RapidIdentity IdP Configuration page.

  13. Click Federation Partners from the Identity Providers left menu items and click the Add Federation Partner drop-down button, select SAML 2.0.

    fed_partner_saml2.png
  14. The Community- SAML Relying Parties workspace loads. Search the list for Salesforce, as the list will be updated on an ongoing basis. If Salesforce is not in the list, click Create New SAML Relying Party+.

    SF_create_new_saml_relying_party.jpg
  15. The Create SAML Relying Party window will load.

    create_saml_sf2.png
  16. Enter the following:

    Return to the RapidIdentity Appliance IdP Configuration page and click Edit Attributes.

    1. Name: Salesforce

    2. Description: Salesforce for SAML

    3. Metadata: Paste the Salesforce metadata in the box.

  17. Click Save.

  18. Salesforce will now be listed as a Federation Partner under the Identity Providers section in theConfiguration module.

    sf_fed_partner2.png
  19. Click SAML Attributes from the action bar.

  20. Select the Name ID tab.

    name_id_tab.png
  21. Click Add Name ID Attribute+.

    1. The example used is for the mail attribute for the username.

  22. Add a Name ID Attribute that contains the Salesforce information.

    create_name_attribute_sf.png
    1. LDAP Attribute: Enter a value that contains the Salesforce username (Ex. "mail").

    2. Name Format Friendly Name: Select "Unspecified" from the drop-down list.

      1. The value will be similar to: "urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified."

  23. Click Save. A confirmation will display at the top of the workspace and the Name ID Attribute will be added.

    sf_saml_name_attributes.png
  24. Return to Federation Partners and select to Edit the Salesforce entry.

    edit_sf_fed_partner.png
  25. Click Attribute Mapping in the Salesforce (SAML) details screen.

    choose_sf_name_attribute.png
  26. Click Choose an Attribute to DENY or PERMIT.

  27. From Add Attribute Mapping, select the newly created attribute from the drop-down

    permit_name_attribute.png
  28. Click Permit to add as a permitted attribute.

  29. A confirmation message will display and requests a Trigger Service Reload. Perform the additional steps first.

    attribute_confirmation.png
  30. From Choose an Attribute to DENY or PERMIT, select the [INTERNAL] SAML Transient ID attribute from the drop-down, if applicable, and click Deny.

  31. From the bottom action buttons, click Trigger Service Reload.

    trigger_reload_action_bar_button.png
  32. After the confirmation appears at the top, return to the IDP Configuration workspace, and click Trigger Web Reload.

    trigger_web_reload.png
  33. When both reloads are complete, access Salesforce from the RapidIdentity Portal, and the <https://{SALESFORCE DOMAIN}.my.salesforce.com >properly configured SAML authentication will direct to the user's homepage.

    sf_app.png
Google SAML Integration Guide - New UI

Google supports a SAML-based Single Sign-On service for its web-based application to configure your Identity Provider (IdP) server connection. In the information provided in the link above, the third party identity provider is Identity Automation through RapidIdentity Federation.

The preliminary SAML authentication configuration steps require that both RapidIdentity Portal and RapidIdentity Federation IdP are internet accessible and are configured as described.

Follow these steps to configure G Suite for SAML. A G Suite Admin Console login is required to complete this configuration.

Note

Google may update their setup sequence without notification, therefore, the steps below may vary slightly.

Launch the Identity Provider Configuration Workspace
  1. From the RapidIdentity Configuration Module, select Identity Providers from the Security menu.

    Identity_providers2.png
  2. The Identity Provider Configuration workspace will launch.

    download_cert_pem.png
  3. Click Download the certificate used by the Identity Provider (.pem) to download the certificate.

    1. Keep this browser window open as the Base URL and Logout URL are necessary during upcoming steps. At that time, the certificate will be uploaded to the G-Suite Admin portal.

    Set up SSO in the G Suite Admin Console
  4. In a different browser window, authenticate to G Suite Admin Console with an administrator account and click Security.

    google_security.png
  5. Click Set up single sign-on (SSO) with a third party IdP. .

    gsuite_sso_option.png
  6. For the Third-party Identity Provider section, enter the information as described below: Sign-in page URL and the Sign-out page URL.

    1. Enter the Sign-in page URL.

    2. Enter the Sign-out page URL.

      Note

      The base URL for these values must be entered using the format: "**/idp/profile/SAML2/Redirect/SSO"

    3. Click REPLACE CERTIFICATE to upload the certificate that was downloaded in Step 3.

    4. Click Save at the bottom of the page to save the configuration.

    set_up_sso_with_a_third_party_idp.png
  7. Click Download IDP Metadata and copy the information to the clipboard. The metadata ends with "</EntityDescriptor>."

    sso_gsuite_metadata.png
  8. Create a SAML 2.0 Federation Partner for G Suite

    In the RapidIdentity Configuration module, click Federation Partners from the Identity Providers section.

    Fed_Partners.png
  9. Click the Add Federation Partner drop-down button and select SAML 2.0.

    fed_partner_saml2.png
  10. The Federation Partners>Community-SAML Relying Parties workspace will launch.

    Community_SAML_Relying_Parti4es4.png

    Tip

    The Community contains basic configuration for commonly used SAML Relying Parties. Before manually adding a new SAML Relying Party, search the Community for the G-Suite entry. The Community will be updated on an ongoing basis with new SAML Relying Parties.

  11. Click Create SAML Relying Party+. Enter the following information in the Federation Partners > Create SAML Relying Party window.

    1. The tables and respective screens below depict the values that are to be entered for each section, "General," and "SSO Settings," for the G Suite Relying Party registration the Register SAML Relying Party window.

      gsuite2.png
    Table 78. General

    Field

    Value

    Name

    G-Suite

    Description

    G Suite SAML Authentication Configuration

    Metadata

    Paste the metadata from the previously copied metadata from the Google Admin console.

    The metadata should appear similar to what is shown in the image; modify the GOOGLE_DOMAIN, as necessary.

    google_metadata.png


    • Click SSO Settings at the bottom of the General page to expand the SSO Settings optons.

      gsuitesso2.png
    1. Table 79. SSO Advanced Settings

      Field

      Value

      Description

      Include SAML2 Attribute Statement

      True

      If selected the SAML2 SSO Assertion generated for this Relying Party will contain an <AttributeStatement> element. Default value.

      SAML2 SSO Assertion Lifetime

      • Hours = 0

      • Minutes = 5

      • Seconds = 0

      Defines the period of time that a SAML2 SSO Assertion generated for this Relying Party will be valid in hours, minutes, and seconds. This setting directly affects the "NotOnOrAfter" attribute in the SAML Assertion which indicates to the Relying Party who receives the Assertion that the Assertion should only be considered valid if it is received before this time instant.

      Sign SAML2 SSO Response

      Conditional

      Determines if the SAML2 SSO Responses should be cryptographically signed. The default value is "Conditional" and should be used to query for assertions that meet particular criteria. Choose "Always" to enable signatures on the Response and "Never" to disable signatures on the Response.

      Sign SAML2 SSO Assertions

      Never

      Determines if the SAML2 SSO Assertions should be cryptographically signed. Choose "Always" to enable signatures on the Response and "Never" to disable signatures on the Response. Default value.

      Encrypt SAML2 SSO Assertions

      Never

      Determines if the SAML2 SSO Assertions should be encrypted. Note: this is only possible if the IdP is provided with an "encryption" certificate in the SAML metadata for the Relying Party. Choose "Always" to enable encryption and "Never" to disable encryption. Default value is "Conditional."

      Encrypt SAML2 SSO Name IDs

      Never

      Determines if the Name IDs present in the SAML2 SSO Assertions should be encrypted. Note: this is only possible if the IdP is provided with an "encryption" certificate in the SAML metadata for the Relying Party. Choose "Always" to enable encryption and "Never" to disable encryption.

      Signature Algorithm

      SHA-1

      The algorithm to use when cryptographically signing the SAML2 SSO Responses and/or SAML2 SSO Assertions.

      • SHA-256: In general, "SHA-256" should be chosen unless the Relying Party does not support it.

      • SHA-1: Use only when the Relying Party does not support SHA-256.

      Skip Endpoint Validation When Signed

      False

      If the <AuthnRequest> is cryptographically signed and if the IdP can successfully verify that signature by using a public signing key present in the Relying Party's metadata, then the IdP can be instructed to comply with an un-recognized Assertion Consumer Service URL by enabling this option.

      Enable ECP Settings

      False

      When selecting the Enable ECP Settings checkbox, the ECP Settings section will become available beneath the SSO Settings along with the configuration options. In this case, ECP settings are not to be enabled.



    DEFINE the LDAP ATTRIBUTES
  12. SAML Service Providers typically define one or more attributes required from the Identity Provider to release to Google during SAML authentication about the authenticating user. These attributes are typically things like Email and Name, but could also be things like Group Membership.

  13. From the Security menu, access to SAML 2.0 Federation Partner that was created earlier in this process. Click SAML Attributes at the bottom of the workspace to view or add attributes.

    gsuitesamlattributes.png
    1. In this example, the Name ID will be the attribute used for authentication.

      1. A SAML assertion typically contains a single "Name ID" attribute and 0 or more other attributes about the authenticated user.

    2. A Name ID attribute is typically the main identifier of the user and is associated with a particular "Name Format." The Name Format generally indicates the type of value to the Relying Party.

      1. For example, a value of "urn:oasis:names:tc:SAML:2.0:nameid-format:email" indicates that the Name ID attribute is an email address.

      2. A value of "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" indicates the value is of an "unspecified" type.

  14. The Federation Partners > SAML Attributes workspace will load. Click the Name ID tab.

    add_name_id_attribute.png
    1. Enter Name ID for the LDAP Attribute, and select the Name Format Friendly Name from the drop-down list. In this example, the name format is an email address.

      1. Refer to the SAML Attributes section for additional information on the available options.

    2. Click Save.

  15. The Name ID attribute will now be populated in the workspace.

  16. From the newly added Name ID Attribute, Click Edit

    saml_name__attributes.png
  17. The urn will be similar to this: "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified." Ensure the SAML version and the format matches the information that is in the metadata from G Suite. In this case, the updated urn will be" urn:oasis:names:tc:SAML:2.0:nameid-format:email ." Click Save.

    edit_urn.png

    Note

    Editing attributes creates a link from the LDAP attributes to the “Name Format” defined by the service provider. Editing attribute mappings specifies what attributes to allow and deny for a specific service provider. It is often recommended to deny the [INTERNAL] SAML Transient ID as in many cases conflicts with some service providers. [INTERNAL] attributes are the attributes defined by default by Rapid Identity to processes SAML interactions between internal apps like the Portal and Connect.

  18. A service reload is required.

    trigger_service_reload2.png
    1. Navigate to IDP Configuration.

    2. Click Trigger Service Reload in the action bar buttons.

    3. A confirmation message will appear briefly at the top of the workspace.

  19. Navigate to the G Suite Admin console, Security section.

  20. Select Set up single sign-on (SSO).

  21. Enter the data fields that were entered in step 2a. These values will vary based on setup.

    google_settings.png
    1. The Sign-in page URL is the IdP Base URL to sign into your system and G Suite.

    2. The Sign-out page URL is the Logout URL for redirecting users to sign out.

    3. The Change password URL is the organization specific URL to allow users to change their password.

  22. Upload the IdP security certificate and ensure Use a domain specific issuer is unchecked. Network masks are optional and organization specific.

    Replace_Certification.png
  23. Create a G Suite App link in the RapidIdentity Portal.

  24. Once the application is created, click the icon in the portal to initiate a valid IdP initiated SAML connection to your G-Suite tenant.

    google_mail.png
  25. Access http://mail.google.com/a/{GOOGLE_DOMAIN}to be directed to a user's homepage.

    gmail.png
OAuth 2.0 Federation Partner Authentication Configuration

There are a variety of web-based applications that support the OAuth 2.0 protocol.

Follow the steps in each section to configure OAuth authentication for RapidIdentity.

  1. From the Configuration menu, select Identity Providers.

    Identity_providers2.png
  2. From the Security section in the left menu items, click the caret to expand the Identity Providers menu and select Federation Partners.

  3. From the Federation Partners workspace, select OAuth 2.0 from the Add Federation Partner selector.

    oauth2_add_from_fed_partners.png
  4. In the Create New OAuth 2.0 Partner window, enter the required information. Refer to the below table for details.

  5. Click Save to add the OAuth 2.0 Partner.

    1. Once the OAuth 2.0 Partner has been saved, in the details of the configuration both a "Client ID" and a "Client Secret Key" field will be displayed. Click the Copy Icon to copy the Client ID to the clipboard.

      partner_id.png
    2. Click the Show Client Secret Key bar to see the key. There is an option to Regenerate Client Secret Key on the bottom action bar.

      regenerate_key.png

Note

If there is at least one External Authentication Realm enabled, a drop-down list will be available on the login page to allow selection of which realm to authenticate against.

Field

Description

Name

Enter name of the OAuth 2.0 Partner

Description

Enter description of the OAuth 2.0 Partner

Internal Realm Name

This value is editable. If a custom name is not used, the internal realm name will be listed as "internal."

Callback URLs

Enter one or multiple callback URLs.

AUTH Code Expiration Seconds

Default value is "60"

Token Expiration Seconds

Default value is "32400"

Allow Refresh Tokens

Select checkbox to allow refresh tokens

Refresh Expiration Seconds

Default value is "2592000"

Attributes

add_attribute.png

Click +Add Attribute and enter the following information:

ldap_attributte.png
  • Type: LDAP is the type.

  • Name: Enter the name of the LDAP attribute, such as displayName.

  • Single Valued: Select this checkbox if there is only one allowable value for the attribute.

  • LDAP Attribute: Enter the LDAP attribute, such as surname or displayName

OpenID Connect

OpenID Connect is an OAuth 2.0 Federation Partner with OpenID Connect Support enabled. Much of the configuration required for OpenID Connect will have already been performed during the OAuth 2.0 setup. View the OpenID Connect Federation Partner section for additional details on configuring OpenID Connect,

OpenID Connect Federation Partners Authentication Configuration

There are a variety of web-based applications that support the OpenID Connect protocol.

OpenID Connect is an OAuth 2.0 Federation Partner with OpenID Connect Support enabled. Much of the configuration required for OpenID Connect will have already been performed during the OAuth 2.0 setup. View the OAuth 2.0 Federation Partner section for additional details on configuring

OpenID Connect

Follow the steps in each section to configure OpenID Connect authentication for RapidIdentity.

  1. From the Configuration menu, select Identity Providers.

    Identity_providers2.png
  2. From the Security section in the left menu items, click the caret to expand the Identity Providers menu and select Federation Partners.

  3. From the Federation Partners workspace, select OpenID Connect from the Add Federation Partner selector.

    connect.png
  4. In the Create New OpenID Connect Partner window, enter the required information. Refer to the below table for details.

  5. Click Save to add the OpenID Connect Partner. After saving an OpenID Connect Partner, the configuration details will display a field for both a "Client ID" and a "Client Secret Key."

Field

Description

Name

Enter the name for the OpenID Connect Federation Partner.

Description

Enter a description for the OpenID Connect Federation Partner.

Callback URLs

Any and all callback URLs requested by the client must be present in this list to be honored.

AUTH Code Expiration Seconds

The number of seconds before authorization codes issued to this client expire. The default value is "60" (1 minute).

Token Expiration Seconds

Default value is "32400."

Allow Refresh Tokens

Select checkbox to designate if refresh tokens should be issued to this client. The default value is "true."

Refresh Expiration Seconds

The number of seconds before refresh tokens issued to this client expire. A value of "0" indicates that refresh tokens do not expire. The default value is "2592000" (30 days).

Attributes

add_attribute.png

If primarily using the OpenID Connect protocol, these values can be left blank, as these attributes are required when operating as an OAuth 2.0 client instead of an OpenID Connect client.

Note

RapidIdentity only supports releasing LDAP attributes to OAuth 2.0 clients.

Field

Description

Name

The name of the attribute when released to the client

LDAP Attribute

The name of the LDAP attribute whose value(s) should be released to the client

Single-Valued

In the event the LDAP attribute contains multiple values, checking this box will release only the first value.

OpenID Connect Configuration

  • Enable OpenID Connect Support: Default = True

    Note

    Checking this means that the Federation Partner is enabled for the OpenID Connect protocol as well.

  • ID Token Lifetime (Seconds): The duration of time in seconds that ID tokens issued to this client should be valid. Default = 60 seconds (1 minute)

  • Sign ID Token (RSA with SHA-256): Whether ID tokens issued to this client should be signed. Default = True

    Note

    At this time, RapidIdentity only supports the RS256 algorithm.

  • Sign User Info (RSA with SHA-256): Whether UserInfo responses for this client should be signed. Default = True

    Note

    At this time, RapidIdentity only supports the RS256 algorithm.

  • Encrypt ID Token (RAS_OAEP_256): Whether ID Tokens issued to this client should be encrypted. Default = False

    Note

    At this time, RapidIdentity only supports the RSA_OAEP_265 encryption algorithm.

  • Encrypt User Info (RSA_OAEP_256): Whether UserInfo responses for this client should be encrypted. Default = False

    Note

    At this time, RapidIdentity only supports the RSA_OAEP_265 encryption algorithm.

  • Encryption Method: If encryption is enabled, then an encryption method must be chosen. RapidIdentity currently supports the following encryption methods:

    • A128CBC_HS256

    • A256CBC_HS512

  • Encryption Key ID (KID): Optional Kid value to include in the ID token header. Some OpenID Connect clients may require this, but it can generally be left blank.

  • RSA Public Key in PEM Format: The public key to use for encryption. This must be a valid RSA public key in PEM format.

    Note

    This is only required if Encryption is enabled for this client.

  • Click Add Claim Attributes and enter the following information:

    • Name: A friendly name of the claim for display purposes

    • Description: Optional Description

    • Attribute Value Type: Defines how a value for the claim is obtained. The following Attribute Value Types are supported:

      • Random - A random string value of a particular length will be generated.

      • Static - A (potentially resolvable) static value will be used. A resolvable static value contains LDAP attribute tokens that will be resolved as the value is being constructed. Example: %givenName% %sn% would be resolved to a value containing the authenticated user's first name, followed by a space, followed by their surname.

      • LDAP - Uses the value(s) of a particular LDAP attribute. This value type supports Binary, which, if checked, causes the attribute value(s) to be treated as binary and the released value(s) will be the Base64 encoded string representation of the binary value(s).

      Note

      The Static and LDAP attribute value types support the following:

      • Regex Filter - If specified, only resolved values that match this regular expression pattern will be considered for release.

      • Single Valued - If checked, only a single value will be released in the event it resolves to multiple values.

    • Claim: The name of the claim as it should be in the ID token and/or UserInfo

    • Claim Type: The value type of the claim. Supported types include:

      • String

      • Boolean

      • Number

      • Object

WS-Federation Partner Authentication Configuration

There are a variety of web-based applications that support the WS-Federation protocol.

Follow the steps in each section to configure WS-Federation authentication for RapidIdentity.

  1. From the Configuration menu, select Identity Providers.

    Identity_providers2.png
  2. From the Security section in the left menu items, click the caret to expand the Identity Providers menu and select Federation Partners.

  3. From the Federation Partners workspace, select WS-Federation from the Add Federation Partner selector.

    ws_federation.png
  4. In the Create New WS-Federation Partner window, enter the required information. Refer to the Create New WS-Federation Relying Party Configuration Table for details.

    creawte_new_federation_partner_ws.png
  5. Click Save to add the WS-Federation Partner.

  6. A confirmation message will display at the top of the page.

    confirmation.png
  7. After the WS-Federation Partner has been created, the Issuer Entity IDs and SAML Audiences & ReplyTo Urls sections will become available. Click the section title, Issuer Entity IDs or SAML Audiences ReplyTo URLs to expand the section and to add entries. Adding, reordering, and deleting entries will not be saved until the Federation Partner is saved. Refer to the Advanced Configuration Table for configuration details.

Table 80. Create New WS-Federation Relying Party Configuration

Field

Description

General

genearl.png
  • Name: Enter the name of the WS-Federation Partner.

  • Realm ID: Enter a unique identifier that the WS-Federation Relying Party identifies itself as, similar to an "EntityID "

  • Description: Enter description of the WS-Federation Partner.

Configuration

configuration.png
  • Token Type: SAML 1.1

  • Token Lifetime (MS): Amount of time in milliseconds for how long the token will be valid

  • Signature Algorithm: RSA SHA-256

  • Signature Digest Algorithm: RSA SHA-256

  • Include <NotBefore> in SAML Assertions? : If checked, the SAML 1.1 assertions generated for this Relying Party will contain the <NotBefore> condition which provides a hard lower bound on the time period which the Relying Party may consider the Assertion valid. If the Relying Party's time source is not quite in sync with the Identity Provider this can be problematic and in that case, this box may be un-checked to leave out that condition.

Attribute Release - Name Identifier

name_id.png
  • Type: Auto-populated based on Token Type selected

  • Name: Represents the plain-language identifier for this attribute

  • Description: Enter a description.

  • Attribute Value Type:The options vary based on the value type selection.

    • Random: Indicates the value should be random.

      • Length: Enter the maximum length accepted for the value

      • Name Qualifier: Optionally, enter a SAML 1.1 Name Qualifier value. If required, this value is generally specified by the Relying Party.

      • Format: Optionally, enter a SAML 1.1 Format value. If required, this value is generally specified by the Relying Party.

    • Static: Allows a set of static values to be specified for this attribute.

      • Resolvable: Allows the static value to contain tokens which can be resolved to real value(s) at the time the SAML Assertion is being generated. For example, If two Static attributes exist, first being "givenname" that contains a user's first name and the second "sn" which contains a user's surname, then a third attribute can be generated representing the first two attributes. The Relying Party could request that the Identity Provider release an attribute called "name" containing the surname followed by a comma and space, then by the first name. This could be accomplished with a "Resolvable" static attribute where the value is defined as "%sn%, %givenName%."

      • Values: Enter limited acceptable value, if applicable

      • +Add Another Value: Click to add additional values

      • Single Valued: Select if there is only one value acceptable

      • Regex Filter: Enter a filter using regular expression syntax, such as wildcards, anchors, and grouping.

      • Name Qualifier: Enter an identifier that has no relation to the user's identity if user's identity is to not be determined based on just the NameID value.

      • Format: Enter the format for the attribute value.

    • LDAP: Returns one or more LDAP attribute values for this assertion attribute.

      • LDAP Attribute: The name of the LDAP attribute holding the values which are intended to be released. Each attribute can have one or more values.

      • Single Valued: Select if there is only one value acceptable

      • Regex Filter: Enter a filter using regular expression syntax, such as wildcards, anchors, and grouping

      • Binary: Enter to identify the attribute length in bytes

      • Name Qualifier: Enter an identifier that has no relation to the user's identity if user's identity is to not be determined based on just the NameID value

      • Format: Enter the format for the attribute value.

Attribute Release - Attributes

release_attributes_main.png

Assign attributes by clicking the +Add Attribute

add_attribute_2.png
  • Type: SAML

  • Name: Enter a name of the attribute.

  • Description: Enter a description.

  • Attribute Value Type: Random, Static, LDAP.

  • Attribute Namespace: Enter a namespace URI, as needed.

WS-Trust Configuration

ws_trust_configuration.png

When the username and password is entered by the end-user during Windows login, some cases the username will match exactly the user's RapidIdentity username or the username will require to be transformed in some manner and possibly mapped to a different LDAP attribute than what RapidIdentity uses natively. Configure either Transform Type or Lookup. Type options.

  • Username Token Mapping Transform Type:

    • No Transform: Do not transform the username

    • Regular Expression Replace: Replaces strings that match a regular expression pattern with a specified replacement string, such as the Windows account name

      • Matching Pattern: Enter the pattern to transform.

      • Replacement: Enter the value to replace when the matching pattern is identified.

  • Username Token Mapping Lookup Type:

    • Native: Uses simple mapping

    • LDAP: Use LDAP query to match user attribute.



Table 81. Advanced Configuration

Field

Description

Issuer Entity IDs

If interaction with a single RapidIdentity IdP is required for multiple domains, such as "Staff" and "Students," unique issuer IDs are used to allow these types of alternate dynamic issuer values based on the user that is authenticating.

Add a new Issuer Entity ID configuration and associate it with a set of users based on a particular LDAP attribute and attribute value pattern.

  1. Click +Add Issuer to set up issuer entity IDs and complete the following values:

    issuer_entity_ids2.png
    1. Issuer ID: (A valid URI or URN): Unique identifier , ex. https://saml.wsfedpartner.com

    2. Type: Is auto-populated - "REGEX"

    3. Attribute: Enter the name of the LDAP attribute.

    4. Pattern: Enter the regular expression pattern for value matching. Here is a link to documentation on Java regular expressions: https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html

    add_issuer_3.png
  2. Click Add.

SAML Audiences & ReplyTo Urls

saml_audiences.png
  • SAML Audiences: Enter a customized list of "Audience" restrictions for the SAML 1.1 assertions generated for this Relying Party. If empty, the Realm ID of the Relying Party will be used.

  • Replyto URLS: Prioritized list of valid URLs to POST the token back to. If a 'wreply' parameter is included in the request, it MUST match one of these or the Realm ID EXACTLY to be honored. If no 'wreply' is included in the request, the first valid URL in this list will be used. If this list is empty and the Realm ID of the Relying Party is a valid URL, that will be used, otherwise the request will result in an error.



Integrating RapidIdentity with a Third-party Identity Provider

Third-party Identity Provider Integration with RapidIdentity
Setting up RapidIdentity to Use a Third-party Identity Provider

This procedure will detail how an Administrator of a third-party Identity Provider (IdP) will set up the integration with RapidIdentity as a Service Provider. The following is an overview of the steps that must be completed to perform the integration:

  1. Gather the SAML metadata for the Identity Provider. These steps will vary based on the Identity Provider that is being used. Refer to the documentation for the Identity Provider to obtain details.

  2. Create a new Service Provider Configuration for RapidIdentity. The Identity Provider's metadata will be required during this step.

    1. Ensure that the Service Provider Entity ID is a unique value.

    2. Provide the IdP logout URL

  3. Set up RapidIdentity as a Relying Party for the Third-party IdP.

  4. Assign the new Service Provider configuration to RapidIdentity.

  5. Test SAML SSO

Create a New Service Provider Configuration for RapidIdentity

When integrating with a third-party IdP, RapidIdentity must be configured to be a Service Provider.

  1. As an administrator, log in to the SAML Identity Provider and retrieve the Federation Metadata XML file.

    Note

    Refer to the third-party IdP documentation for additional details on locating the metadata.xml file.

  2. Log in to the RapidIdentity portal as an Administrator and access the Service Providers section from the Configuration workspace.

    service_providers.png
  3. Click the Register Service Provider+ button.

    new_add_saml_2.png
  4. The Register Service Provider window will open.

    new_saml_4.png
    1. Hover over the question marks (?) for additional information on completing the fields and for an example.

  5. The table below describes how to complete the Service Provider information. Fields with an asterisk (*) depict a required field.

    Field

    Description

    Name

    Enter a name for the Service Provider. For example, RapidIdentity to <Third-party IdP>.

    Description

    Optionally, enter a description for the service provider.

    Entity ID*

    The unique identifier for RapidIdentity as the SAML 2.0 Service Provider. When federating with a particular Identity Provider, it must be unique among all of the Relying Parties the Identity Provider federates with.

    This value must be a valid URI or URN and it is recommended to use the base RapidIdentity URL (e.g. "https://{host}/"). For example, <https://localhost.riexample.com/thirdpartyidp>.

    Base URL

    Enter the URL from which to construct SAML endpoints; the URL must be comprised of protocol, server, port, and context path. The URL is the base URL to the Rapididentity instance (e.g. "https://{host}[:{port}]/").

    This can be exactly the same as the Entity ID, but is not a requirement. For example, <https://localhost.riexample.com>.

    Logout URL*

    A URL to redirect the user's browser to after logging out of the local RapidIdentity session. This typically points to the logout URL of the Identity Provider, such as "https://idp-host/idp/logout."

    The URL must be comprised of protocol, server, port, and context path.

    Organization Name

    Enter the name of the organization associated with the provider. Optional, and if specified, shows up in the Service Provider's SAML 2.0 metadata.

    Organization URL

    Enter the website of the organization associated with the provider. Optional, and if specified, shows up in the Service Provider's SAML 2.0 metadata.

    Contact Email Address

    Email address for the contact at the organization. Optional, and if specified, shows up in the Service Provider's SAML 2.0 metadata.

    IDP Metadata*

    Paste the XML metadata from the third-party IdP.

    Tip

    A metadata URL can not be used as metadata.

  6. After entering the required information, click Save.

    1. The service provider configuration will be listed in the workspace and can be made active by "Assigning" it in RapidIdentity. Refer to Assign the Third-Party IdP to RapidIdentity for details.

Set up RapidIdentity as a Relying Party for the Third-party Identity Provider

It is necessary to create a relying party in the third-party Identity Provider. A relying party object consists of a variety of identifiers, names, and rules that identify this partner to the local Federation Service.

In order to successfully integrate with any third-party IdP, that IdP is required to return either the idautoID or the unique email address of the authenticating user.

  1. Release the idautoID value:

    1. The IdP instance must be able to communicate with a datastore that contains the idautoID attribute, such as an Active Directory DC.

    2. Must be released as "idautoid" (case-insensitive) or "urn:idauto.net:saml:attribute:idautoID".

  2. Release the unique email address:

    1. RapidIdentity is required to have the same value provisioned in its backing directory where the email address is unique.

    2. Must be released as "mail", "email", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" or "http://schemas.xmlsoap.org/claims/EmailAddress"

    Note

    When RapidIdentity receives a SAML assertion with multiple email address values (and no idautoID), the values will be processed in the order received and the first one which uniquely identifies a User will be accepted.

  3. Follow the configuration steps for creating a relying party for RapidIdentity in the third-party IdP.

Assign the Third-party Identity Provider to RapidIdentity

After creating a new service provider configuration for RapidIdentity with a third-party IdP, RapidIdentity will be listed as a service provider in the workspace and can be assigned applications for login.

Tip

It is helpful to open an additional browser window and log in to the RapidIdentity Portal simultaneously before altering the Service Provider configuration. This will allow an administrator to cancel changes in the case of an error during configuration.

  1. RapidIdentity as a service provider will be listed in the workspace and can be assigned applications for login. Refer to Assign the third-party IdP to RapidIdentity for details.

    new_saml_5.png
    1. If successful, the Assigned to RapidIdentity column will display a "Yes" value. A brief confirmation message, "Saved" will be displayed at the top of the workspace.

  2. Close all browser sessions.

  3. You should be forwarded to the third-party IdP for authentication.

Test SAML SSO for the Third-party IdP

In a new browser window navigate to RapidIdentity.

If configured properly, users should be redirected to the third-party IdP to authenticate. Once authenticated, when accessing RapidIdentity, you should be logged in.

Integrating RapidIdentity with ADFS as a Third-party Identity Provider

Configuring ADFS as a SAML Identity Provider for RapidIdentity

This procedure will detail how an ADFS Administrator will configure ADFS as an Identity Provider (IdP) for RapidIdentity as a Service Provider.

When users access RapidIdentity they are directed to ADFS to authenticate. Once the user authenticates successfully in ADFS they will be redirected to RapidIdentity.

Refer to the following sections for details on the integration and configuration.

Set up the Service Provider Configuration in RapidIdentity

This procedure will detail the first step of how an ADFS Administrator will set up the integration with RapidIdentity as a Service Provider.

  1. As an administrator, log in to ADFS and retrieve the Federation Metadata XML file.

    Note

    Refer to the ADFS documentation for additional details on locating the metadata.xml file.

  2. Log in to the RapidIdentity portal as an Administrator and access the Service Providers section from the Configuration workspace.

    service_providers.png
  3. Click the Register Service Provider+ button.

    new_add_saml_2.png
  4. The Register Service Provider window will open.

    new_saml_4.png
    1. Hover over the question marks (?) for additional information on completing the fields and for an example.

    2. The table below describes how to complete the Service Provider information.

      Field

      Description

      Name

      Enter a name for the Service Provider. For example, RapidIdentity to ADFS.

      Description

      Optionally, enter a description for the service provider.

      Entity ID

      The unique identifier for RapidIdentity as the SAML 2.0 Service Provider. When federating with a particular Identity Provider, it must be unique among all of the Relying Parties the Identity Provider federates with. This value must be a valid URI or URN and it is recommended to use the base RapidIdentity URL (e.g. "https://{host}/"). For example, <https://localhost.riexample.com/ADFS>.

      Base URL

      Enter the URL from which to construct SAML endpoints; the URL must be comprised of protocol, server, port, and context path. and is the base URL to the Rapididentity instance (e.g. "https://{host}[:{port}]/"). This can be exactly the same as the Entity ID, but is not a requirement. For example, <https://localhost.riexample.com>.

      Logout URL

      A URL to redirect the user's browser to after logging out of the local RapidIdentity session. This typically points to the logout URL of the Identity Provider, such as "https://idp-host/idp/logout." The URL must be comprised of protocol, server, port, and context path. Click to automatically populate with the current IdP logout URL. For example, <https//:3rdpartyidp.com/signout>.

      Organization Name

      Enter the name of the organization associated with the provider. Optional, and if specified, shows up in the Service Provider's SAML 2.0 metadata.

      Organization URL

      Enter the website of the organization associated with the provider. Optional, and if specified, shows up in the Service Provider's SAML 2.0 metadata .

      Contact Email Address

      Email address for the contact at the organization. Optional, and if specified, shows up in the Service Provider's SAML 2.0 metadata.

      IDP Metadata

      Paste the XML metadata from the server.

      Tip

      A metadata URL can not be used as metadata.

  5. Export the Service Providers' metadata.

  6. After entering the required information, click Save. The RapidIdentity service provider will be listed in the workspace and can be assigned applications for login.

  7. To activate this Service Provider configuration and enable SAML authentication for RapidIdentity, select the entry in the list and click Assign to RapidIdentity in the action bar.

    new_saml_5.png
    1. If successful, the Assigned to RapidIdentity column will display a "Yes" value. A brief confirmation message, "Saved" will be displayed at the top of the workspace.

Set up a Relying Party Trust in ADFS

It is necessary to create a relying party trust in ADFS. A relying party trust object consists of a variety of identifiers, names, and rules that identify this partner to the local Federation Service.

Tip

It is helpful to open an additional browser window and log in to the RapidIdentity Portal simultaneously before altering the Service Provider configuration. This will allow an administrator to cancel changes in the case of an error during configuration that may prevent logging back in as an administrator.

  1. Log in to ADFS and navigate to the ADFS Management application.

  2. Click Relying Party Trusts and choose Add Relying Party Trust... to launch the wizard.

  3. Click Claims aware

    1. Claim tokens are issued by the IdP after authenticating the user. The login for the application will be the Service Provider, RapidIdentity.

  4. Either import the Service Provider metadata or choose Enter data about the relying party manually.

    Tip

    For ease of access, import the metadata from a local file and name it a Display Name of "RapidIdentity."

  5. In the Choose Access Control Policy step, select Permit everyone.

  6. In the Ready to Add Trust option, no additional configuration is required.

Configuring the Claim Issuance Policy

In this step, ADFS will be configured to release assertion attributes to RapidIdentity. In order to successfully integrate with ADFS as an IdP, either the idautoID or the unique email address of the authenticating user must be returned.

  • Release the idautoID value:

    • Possible if the IdP instance can communicate with an Active Directory DC which contains that attribute.

    • Must be released as "idautoid" (case-insensitive) or "urn:idauto.net:saml:attribute:idautoID."

  • Release the email address:

    • RapidIdentity is required to have the same value provisioned in its backing directory and the email address is unique.

    • Must be released as "mail", "email", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" or "http://schemas.xmlsoap.org/claims/EmailAddress."

Note

When RapidIdentity receives a SAML assertion with multiple email address values (and no idautoID), the values will be processed in the order received. The first value which uniquely identifies a User will be accepted.

Configuring the Release of idautoID
  1. In ADFS Management, navigate to Claim Description and choose Add Claim Description.

  2. Enter the required values. Below is a sample of values to be entered.

    Table 82. Claim Description Values

    Field Name

    Value

    Display Name

    IDautoID

    Short Name

    idautoID

    Claim Identifier

    idautoID

    Description

    <blank>

    <Publish this claim description...>

    <both boxes unchecked>



  3. Navigate to Relying Party Trusts and choose the "RapidIdentity" relying party. Select Edit the Claim Issuance Policy.

    1. Click Add Rule....

    2. Choose the Send LDAP Attributes as Claims claim rule template.

    3. Name the Claim rule similar to "Send IdautoID."

    4. Choose the Active Directory attribute store.

    5. Map the "IdautoID" LDAP Attribute to the "IdautoID" Outgoing Claim Type.

    6. Click Finish and then OK to finish editing the Claim Issuance Policy.

Configuring the release of Email Address
  1. Navigate to Relying Party Trusts and choose the "RapidIdentity" relying party.

  2. Click Edit the Claim Issuance Policy.

  3. Click Add Rule.

  4. Chose the "Send LDAP Attributes as Claims" claim rule template.

  5. Name the claim rule similar to "Send Email Address."

  6. Choose the Active Directory Attribute store.

  7. Map the E-Mail-Addresses LDAP Attribute to the E-Mail Address Outgoing Claim Type.

  8. Click Finish and then click OK to complete editing the Claim Issuance Policy.

Test SAML SSO with ADFS

In a new browser window navigate to RapidIdentity.

If configured properly, users should be redirected to ADFS to authenticate. Once authenticated, when accessing RapidIdentity, you should be logged in.

Editing the Web Template

The RapidIdentity Federation login page supports CSS configuration enhancements to allow organizations to brand their login page to best serve their organization and user population.

Follow these steps to edit the web template used in the login screen.

  1. From the Portal Module Selector, choose Configuration. Then in the Security menu, choose Identity Providers.

    configuration_identity.png
  2. From the Left Menu Items, select Web Template.

    webtemplatemenu.png
  3. The Edit IDP Web Customizations page contains fields to edit the HTML web template. Click a checkbox to activate a function, or enter text in the blank field for the selection to enter the value.

    edit_the_web_template.png

    Field

    Description

    Load Helplinks in Same Tab/Window

    Allows administrators to determine whether the Forgot My Username and Forgot My Password dialogs open in new tabs or windows, based on the current browser configuration. If checked, the dialog boxes will load in the same tab or window; if unchecked, these dialog boxes proceed in different browser tabs. Currently, in order to facilitate the same tab or window feature, the help links are loaded in an <iframe>.

    Page Title

    Enter a title for the web template for the login page

    Favicon URL

    Used to include a URL for the browser to display a logo

    Expired Password Text

    Enter the message to be displayed when a user enters an incorrect password. Ex. "Click HERE to change your password."

    Expired Password Link

    Enter the link to direct user to when a user enters an incorrect password. Ex. "/arms/expired-password"

    The Expired Password links point to either the RapidIdentity Portal server location or the organization's Forgotten Username/Password servers. If these two fields are left blanks, users will not see these options.

    Custom Logo Image URL

    Enter a URL for a custom logo image. After entering a URL for a logo image, a box appears underneath called "Custom Logo Preview" to show the image that was entered.

    Header Background Color, Header Text Color, Body Background Color, Body Text Color

    Basic mode is the default mode and allows administrators to configure colors from a color picker to be configured. For each of these four selections, optionally click the drop-down for the color box, and customize the scheme.

    color_scheme_dropdown.png

    Enable Custom CSS (Advanced) , Enable Custom HTML (Advanced)

    Advanced mode allows administrators to configure the login page through writing their own CSS and also to include HTML for additional divisions.

    Click the checkbox to allow Administrators to use CSS to configure the login page further to suit any organization's branding requirements. To ensure Basic mode color selections are retained upon upgrade, click the Enable Custom CSS (Advanced) checkbox. Custom styling from versions prior to 3.5 are not migrated.

    Note

    Any valid HTML entered into the text area will manifest as new HTML on the login pages. Note that javascript included in Custom HTML is not supported and will not function as expected.

    An authentication policy has to be activated for Custom HTML to function properly.

    Note

    Custom HTML is invisible by default, but can be made visible by CSS. You must add the CSS visibility property to the Custom CSS field and set it to visible as it applies to the custom HTML. For example, if your custom HTML uses a <div> tag, you would need to add the following code to the Custom CSS:

    .custom-html{
        height:auto;
        visibility:visible;
    }

    For additional information on CSS, refer to CSS Styling later in this topic.

    Logout Body

    Allows administrators to write custom HTML to be included in the body of the logout web page. Administrators can include, for example, custom messages and styling to redirect users to a different site. Use {i18n:<key>} syntax in the custom HTML to localize it. Those custom i18n values can, themselves, contain HTML.

  4. Click Trigger Web Reload at the bottom of the workspace to activate the changes or Reset to Defaults to overwrite any updates.

To ensure customizations are not modified from future product development updates, reference specific CSS identifiers/selectors with the prefix ".cs-" as shown in the screenshot below.

login_webtemplate.png

Letter

CSS identifiers with the prefix ".cs-"

Style

A

".cs-body"

Page Body Style

B

".cs-header"

Page Header Style

C

".cs-heading"

Heading Text

D

".cs-login-logo"

Logo Image

E

".cs-button-aslink"

Help Links

F

".cs-button"

Primary Buttons

G

".cs-wrapper.content"

Body Below Header

CSS Styling

Custom CSS styling may be written as follows:

.cs-wrapper 
{ background-color: #afbce1; } 
.cs-login-logo 
{ background: url(//abc.def.com/example); } 
.cs-header 
{ background-color: #0d66b2; } 
.cs-button 
{ color: #0d66b2; background-color: #d7ddf0; } 
.cs-button:hover 
{ color: #d7ddf0; background-color: #0d66b2; } 
.cs-button-aslink 
{ top: 240px; } 

More advanced, custom CSS styling configurations are possible. One example is shown below.

signin.png

The whitespace above the light blue box containing the username and password fields is reserved for the official organization logo. The CSS for this particular configuration for use as a representative example to edit is as follows:

.cs-body, .cs-wrapper {
    background-color: #fff;
    font-family: 'Century Gothic', Arial, sans-serif;
}
.cs-container {
    position: relative;
}
.cs-header {
    display: none;
}
.cs-login-logo {
    margin: auto;
    width: 192px;
    height: 100px;
    margin-bottom: 40px;
    background-image: url(http://[yourOrganizationLogoUrlWithImageExtention);
    background-size: 192px 102px;
}
.cs-login-container {
    text-align: center;
    color: #0032a0;
    font-size: 16px;
    clear: left;
    padding: 20px;
    border: 1px solid #c4cfe6;
    background: #E3EAFC;
    border-radius: 20px;
    box-shadow: 0px 2px 7px rgba(100,140,220,.6);
}
.cs-login-container:after {
    content: "For password help call 123-456-7890";
    font-size: 12px;
}
.input {
    display: block;
    width: 100%;
    height: 40px;
    margin-bottom: 15px;
    padding-right: 10px;
    padding-left: 10px;
    background-color: #F6F8FF;
    border-radius: 3px;
    color: #445963;
    outline: 0;
    border: 1px solid #e6e6e6;
}
.cs-button-wrapper {
    margin: 0;
}
.cs-button[type="submit"] {
    background-color: #0032a0;
    color: #F9F9F9;
    width: 80px;
    height: 80px;
    text-indent: -99999px;
    line-height: 0;
    border-radius: 100px;
    margin: 40px 0;
}
.cs-button[type="submit"]::after {
    content: "Sign In";
    text-indent: -18px;
    display: block;
    line-height: initial;
    font-weight: 300;
}
.cs-button[type="button"] {
    background-color: transparent;
    text-indent: -99999px;
    line-height: 0;
    background: url(https://www.wpclipart.com/signs_symbol/button/
        metal_buttons/arrow_button_metal_blue_right.png) 
        240px center no-repeat;
    background-size: 20px 20px;
}
.cs-button[type="button"]:hover {
    background-color: transparent;
}
.cs-button[type="button"]::after {
    content: "New users set up your account";
    text-indent: 0;
    display: block;
    color: #0032a0;
    font-size: 12px;
    font-weight: normal;
    font-family: 'Century Gothic', Arial, sans-serif;
}
.cs-nav-next-button {
    background-image: none;
}
.claim-account-text, .cs-heading-container {
    display: none;
}
.need-help-link {
    margin: 0;
    display: inline-block;
    position: absolute;
    top: 310px;
    right: 55px;
}
.cs-button-aslink {
    color: #2749A5;
    font-size: 10px;
    float: none;
    margin: 0;
}
.button:hover {
    background-color: #021a4c;
    transition: background-color 60ms ease-out;
}
.placeholder-container {
    position: relative;
}
span.placeholder-text {
    display: block;
    top: 0;
    left: 15px;
    color: #2749A5;
    font-size: 12px;
}
.placeholder-input {
    position: relative;
    top: 16px;
    border-radius: 30px;
}
.input-toggle {
    background-image: none;
    width: 80px;
    top: -2px;
    color: #2749A5;
}
.input-toggle::after {
    content: "Show Password";
    font-size: 10px;
}
#pwd {
    margin-top: 30px;
}
::-webkit-input-placeholder { /* WebKit browsers */
    color:    #fff;
}
:-moz-placeholder { /* Mozilla Firefox 4 to 18 */
    color:    #fff;
    opacity:  1;
}
::-moz-placeholder { /* Mozilla Firefox 19+ */
    color:    #fff;
    opacity:  1;
}
:-ms-input-placeholder { /* Internet Explorer 10+ */
    color:    #fff;
}
.error-message {
    margin-bottom: 0;
    margin-left: 16px;
    padding-top: 5px;
    font-size: 12px;
}
.content:after {
    content: "Please note that the use of the [organizationName] 
        network, computer equipment, and resources are not private 
        and may be monitored for appropriate use. For further 
        information, please refer to the [organizationName] 
        Acceptance Use Policy to understand appropriate use.";
    text-align: center;
    width: 310px;
    margin: 40px auto;
    font-size: 12px;
    color: grey;
} 
Configure External Authentication Realms

Follow these steps to configure External Authentication Realms:

  1. From the Module Selector, click Configuration. From the Security section, click Identity Providers.

    Identity_providers2.png
  2. Click External Auth Realms from the left menu items.

    ext_realm2.png
  3. Click Create Realm.

    Table 83. Create External Authentication Realm

    Field

    Value

    Description

    Type

    Select LDAP from the drop-down menu

    Required Field: complete to suit organizational needs

    Name

    Enter a name for the realm

    Required Field: complete to suit organizational needs

    Description

    Enter a description for the realm

    Complete to suit organizational needs

    Enabled

    True

    Enables the new realm upon saving

    Default

    True

    Sets the realm as the default

    LDAP Server Set

    Select a server set for the realm

    Select the new LDAP server set that was created

    Internal User Filter

    Click Fix in LDAP Builder to enter the LDAP Filter

    The copy icon can be used to copy the filter to the clipboard

    Fix in LDAP Builder

    Click to open the LDAP Filter search

    Complete to suit organizational needs

    Remote Search Base DN

    Enter a distinguished name for search

    Complete to suit organizational needs

    Remote Username Attribute

    This value is largely dependent on organizational preference and LDAP structure

    This value is most often the value the end user will type during remote login. Common values include, but not limited to, cn, mail, sAMAccountName, userPrincipalName, and uid.

    Remote User Filter

    Complete to suit organizational needs

    Click Fix in LDAP Builder to enter the LDAP Filter



  4. To add external or internal attributes, under Attribute Map Items, click Add Item.

    add_item.png
  5. Enter the External and Internal Attributes. If two or more realms exist, check the default box to assign a default external authentication realm. Unless the Internal Realm Name is changed, it will display as "Internal."

    Note

    When at least one External Authentication Realm is enabled, users will see a drop-down on the login page that allows them to choose which realm to use for authentication.

    external_attribute.png
  6. When complete, click Save. The new realm now displays in the Current Realms box. At this point, configuring support for multiple LDAP servers is complete.

Trusted IdPs

In the Federation Authentication Method, RapidIdentity Federation acts as a SAML 2.0 Relying Party to a RapidIdentity Identity Provider or a third-party SAML Identity Provider.

When configuring the Federation Authentication Method for an Authentication Policy, you must choose a previously configured Trusted Identity Provider. Therefore, a Trusted Identity Provider contains all of the configuration necessary to facilitate SAML 2.0 SSO between RapidIdentity Federation and a third-party SAML 2.0 Identity Provider.

SAML 2.0 Trusted IdPs are configured similarly to RapidIdentity Trusted IdPs, but instead of having the fields host and port, they require the fields loginUrl and binding.

Note

If the Trusted IdP is in a domain different from RapidIdentity, you may need to add that domain as an Allowed Origin in the RapidIdentity CORS Security Configuration. The Allowed Origin value should take the form https://trusted_idp_domain.

To add a new IdP, click Add Trusted Identity Provider.

Trusted_IdPs.jpg

A pop-out window will open with form fields. On the General tab, enter the information as provided by the identity provider.

Create_Trusted_IDP.jpg

Field

Description

Name

Required field - give the IdP a meaningful name

Description

Optional description if desired

Entity ID

The SAML 2.0 Entity ID of the third-party Identity Provider

Type

The Identity Provider to be used when composing SAML responses. RapidIdentity makes it simple to point to an external RapidIdentity Identity Provider

*Host

The hostname of the remote RapidIdentity Identity Provider

*Port

The port the Identity Provider is to use with requests. This defaults to 443

Signing Certificate

Cut and paste the provider's certificate into this box

At the bottom of this menu is an option to add Configuration Attribute Mappings. This option allows administrators to map attributes from the local Identity Provider to the remote Identity Provider. To match the same user in both systems, both systems must have a uniquely identifying attribute for each user. For example, if email address is the unique identifier, configure the Local field with the attribute name for email (e.g., "mail"), and the Remote field with the same attribute as it is named in the other system (e.g., "emailAddress").

Note

Attribute Mapping supports a special remote attribute value: @NameID. This indicates that the NameID attribute returned from the Remote Identity Provider should be mapped to the specified Local attribute.

Trusted_IdPs_-_Configuration_Attribute_Mappings.png