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.
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:
IdP session timeout expires
User logs out of Portal, which redirects to the IdP logout
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)
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
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.
From Configuration, click Identity Providers in the Security options.
New Identity Provider Setup
If the Identity Provider has not yet been set up, follow the below steps.
From Identity Providers, select IDP Configuration and click Create New Configuration.
From the Identity Provider Configuration window enter the following values:
Identity Provider Configuration Type*: Automatic/Quick Configuration
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.
The Identity Configuration workspace will then be populated with the Identity Provider Configuration data. Click here for more information on Identity Provider configuration data.
From the Configuration menu, click Integration from the Security section.
From the Integration menu, click Federation.
Federation Hostname: "localhost'
Federation Username: Enter your domain adminstrator's name
Federation Debug Level: None
Click Update Password.
Enter the Domain Administrator's password.
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
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.
Log into your Portal using the Domain Administrator account used above in the IdP configuration as the Internal-Appliance Configuration-LDAP.
Answer the Setup Security Questions.
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.
 |
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. Requests from that session are only considered valid when used from that same IP address. WarningChecking this box can cause users to be forced to re-authenticate from devices any time their connection changes cell towers or wireless access points, or when the DHCP lease expires. |
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.
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.
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.
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 (IdP) 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.
Access the SAML SSO Advanced Settings from the Configuration menu and select Federation Partners from the left-hand menu items.
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.
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.
The Community Federation Partners workspace will load. Refer to the Community section to learn more about that topic.
Click Create SAML Relying Party to open the configuration options.
Enter all relevant settings in the General section.
Field
Description
Name (Required)
Give the Relying Party a unique name.
Description (Optional)
Provide a short but accurate description if desired.
Is InCommon
Check this box if the Relying Party is a registered entity in the InCommon Federation.
Note
This will require two specific Attributes to be added and open a Metadata Refresh Interval* field. Metadata must be pulled from an InCommon configuration for this setting.
*Metadata Refresh Interval (Hours) -- InCommon Only
Set the interval in hours between RapidIdentity refreshing the Relying Party's metadata by retreiving it from the InCommon Metadata Service. Valid refresh intervals are from 1-24 hours.
Metadata (Required)
Enter the metadata for the Relying Party.
From the Federation Partners configuration screen, click on SSO Settings.
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.
 |
When selecting the Enable ECP Settings checkbox, the ECP Settings section will become available beneath the SSO Settings along with the configuration options.
 |
|
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 assignments will have been set up already under the Federation Partners SAML Attributes section.
Select the Federation Partner from the Federation Partners workspace, and click Edit by hovering in the last column.
From the Federation Partners window, scroll down to Attribute Mapping.
Click Choose an Attribute to DENY or PERMIT.
Click to expand the drop-down of available attributes to deny or permit mapping.
The Add New Attribute window will load. Select the attribute type from the drop-down.
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.
For InCommon configurations, the two following attributes must be set:
eduPersonPrincipalName - this attribute must correspond to the name of the user
eduPersonScopedAffiliation - this attribute must correspond to the user's relationship to the institution (e.g., Student, Teacher, etc.)
Note
An error message will display until these attributes are configured.
Select to Permit or Deny the attribute mapping.
Click Add New Attribute+ to add additional SAML attributes. Repeat steps 2-8.
Click Save to add the attribute to the selected Federation Partner.
A confirmation notice will display if updates are successful.
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.
From the Configuration menu, select Identity Providers from the Security menu.
Expand Identity Providers in the left hand menu items and click Federation Partners.
Click Add Federation Partner and select SAML2.0 from the drop-down selector.
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.
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.
Note
The SAML Attributes icon will only display if there are SAML Federation Partners in the system.
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.
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.
Click the Add LDAP Attribute + button to open the LDAP attribute window.
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.
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."
Friendly Name: This is the name as the LDAP attribute will appear in the SAML Assertion.
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."
Unspecified: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
URI Reference: urn:oasis:names:tc:SAML:2.0:attrname-format:uri
Basic: urn:oasis:names:tc:SAML:2.0:attrname-format:basic
Custom Name Format: The format value is a free form text field to enter the custom name format.
Name Format Value: The format will adjust based on the Name Format Friendly Name selected
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.
Click the Add Static Attribute + button to open the Create Static Attribute window.
Friendly Name: This is the name as the Static attribute will appear in the SAML Assertion.
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."
Values: Enter the Static Attribute
Click +Add Another Value to enter multiple acceptable values
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%."
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.
Unspecified: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
URI Reference: urn:oasis:names:tc:SAML:2.0:attrname-format:uri
Basic: urn:oasis:names:tc:SAML:2.0:attrname-format:basic
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.
Name Format Value: This value will adjust based on the Name Format Friendly Name selected.
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.
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.
LDAP Attribute: Enter the name of the LDAP Attribute
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.
Unspecified: Allows a free from entry (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)
Email Address: Uses the email format ( (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)
X.509 Subject Name: Uses the subject name of the X509 Certificate (urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName)
Windows Domain Qualified Name: Uses the FQDN of the hostname and domain name (urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName)
Kerberos Principal Name: Uses the Principal Name to identify the user or service (urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos)
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)
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)
Transient Identifier: An identifier intended to be used for a single session only (urn:oasis:names:tc:SAML:2.0:nameid-format:transient)
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.
Name Format Value: This value will adjust based on the Name Format Friendly Name selected.
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.
Click Add Static Name ID Attribute+.
Values: Enter a Name ID Attribute
Click +Add Another Value to enter multiple acceptable values
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%."
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.
Unspecified: Allows a free from entry (urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified)
Email Address: Uses the email format (urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress)
X.509 Subject Name: Uses the subject name of the X509 Certificate (urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName)
Windows Domain Qualified Name: Uses the FQDN of the hostname and domain name (urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName)
Kerberos Principal Name: Uses the Principal Name to identify the user or service (urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos)
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)
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)
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.
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:
RapidIdentity Pre-configured SAML Relying Parties (Using the Community)
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.
From the RapidIdentity Configuration Module, select Identity Providers from the Security menu.
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.
The Community-SAML Relying Parties workspace will launch.
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.
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.)
Hover over an entry in the Community - SAML Relying Parties workspace and click Import.
A confirmation message will appear and the imported SAML Relying Parties will be imported into the Federation Partners workspace and will display.
All information to register the SAML Relying Party will automatically be configured. Click Edit next to the SAML Relying Party to view the details.
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.
From the RapidIdentity Configuration Module, select Identity Providers from the Security menu.
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 ValuesField 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
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.
Log in to the service provider, Salesforce, as an administrator.
Navigate to the Setup Gear, and select Setup.
Search in Setup for Single Sign-On Settings.
Click New and fill out the form using the data from Step 2, including the Certificate.
Click Save.
Navigate to Security Controls | Single Sign-on Settings.
Click on the Name of the SSO (IdAuto_IDP).
Click Download Metadata.
Return to the RapidIdentity IdP Configuration page.
Click Federation Partners from the Identity Providers left menu items and click the Add Federation Partner drop-down button, select SAML 2.0.
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+.
The Create SAML Relying Party window will load.
Enter the following:
Return to the RapidIdentity Appliance IdP Configuration page and click Edit Attributes.
Name: Salesforce
Description: Salesforce for SAML
Metadata: Paste the Salesforce metadata in the box.
Click Save.
Salesforce will now be listed as a Federation Partner under the Identity Providers section in theConfiguration module.
Click SAML Attributes from the action bar.
Select the Name ID tab.
Click Add Name ID Attribute+.
The example used is for the mail attribute for the username.
Add a Name ID Attribute that contains the Salesforce information.
LDAP Attribute: Enter a value that contains the Salesforce username (Ex. "mail").
Name Format Friendly Name: Select "Unspecified" from the drop-down list.
The value will be similar to: "urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified."
Click Save. A confirmation will display at the top of the workspace and the Name ID Attribute will be added.
Return to Federation Partners and select to Edit the Salesforce entry.
Click Attribute Mapping in the Salesforce (SAML) details screen.
Click Choose an Attribute to DENY or PERMIT.
From Add Attribute Mapping, select the newly created attribute from the drop-down
Click Permit to add as a permitted attribute.
A confirmation message will display and requests a Trigger Service Reload. Perform the additional steps first.
From Choose an Attribute to DENY or PERMIT, select the [INTERNAL] SAML Transient ID attribute from the drop-down, if applicable, and click Deny.
From the bottom action buttons, click Trigger Service Reload.
After the confirmation appears at the top, return to the IDP Configuration workspace, and click Trigger Web Reload.
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.
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.
From the RapidIdentity Configuration Module, select Identity Providers from the Security menu.
The Identity Provider Configuration workspace will launch.
Click Download the certificate used by the Identity Provider (.pem) to download the certificate.
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 In a different browser window, authenticate to G Suite Admin Console with an administrator account and click Security.
Click Set up single sign-on (SSO) with a third party IdP. .
For the Third-party Identity Provider section, enter the information as described below: Sign-in page URL and the Sign-out page URL.
Enter the Sign-in page URL.
Enter the Sign-out page URL.
Note
The base URL for these values must be entered using the format: "**/idp/profile/SAML2/Redirect/SSO"
Click REPLACE CERTIFICATE to upload the certificate that was downloaded in Step 3.
Click Save at the bottom of the page to save the configuration.
Click Download IDP Metadata and copy the information to the clipboard. The metadata ends with "</EntityDescriptor>."
Create a SAML 2.0 Federation Partner for G Suite In the RapidIdentity Configuration module, click Federation Partners from the Identity Providers section.
Click the Add Federation Partner drop-down button and select SAML 2.0.
The Federation Partners>Community-SAML Relying Parties workspace will launch.
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.
Click Create SAML Relying Party+. Enter the following information in the Federation Partners > Create SAML Relying Party window.
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.
Table 78. GeneralField
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.
Click SSO Settings at the bottom of the General page to expand the SSO Settings optons.
- 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 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.
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.
In this example, the Name ID will be the attribute used for authentication.
A SAML assertion typically contains a single "Name ID" attribute and 0 or more other attributes about the authenticated user.
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.
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.
A value of "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" indicates the value is of an "unspecified" type.
The Federation Partners > SAML Attributes workspace will load. Click the Name ID tab.
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.
Refer to the SAML Attributes section for additional information on the available options.
Click Save.
The Name ID attribute will now be populated in the workspace.
From the newly added Name ID Attribute, Click Edit.
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.
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.
A service reload is required.
Navigate to IDP Configuration.
Click Trigger Service Reload in the action bar buttons.
A confirmation message will appear briefly at the top of the workspace.
Navigate to the G Suite Admin console, Security section.
Select Set up single sign-on (SSO).
Enter the data fields that were entered in step 2a. These values will vary based on setup.
The Sign-in page URL is the IdP Base URL to sign into your system and G Suite.
The Sign-out page URL is the Logout URL for redirecting users to sign out.
The Change password URL is the organization specific URL to allow users to change their password.
Upload the IdP security certificate and ensure Use a domain specific issuer is unchecked. Network masks are optional and organization specific.
Create a G Suite App link in the RapidIdentity Portal.
Once the application is created, click the icon in the portal to initiate a valid IdP initiated SAML connection to your G-Suite tenant.
Access http://mail.google.com/a/{GOOGLE_DOMAIN}to be directed to a user's homepage.
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.
From the Configuration menu, select Identity Providers.
From the Security section in the left menu items, click the caret to expand the Identity Providers menu and select Federation Partners.
From the Federation Partners workspace, select OAuth 2.0 from the Add Federation Partner selector.
In the Create New OAuth 2.0 Partner window, enter the required information. Refer to the below table for details.
Click Save to add the OAuth 2.0 Partner.
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.
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.
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 |
Click +Add Attribute and enter the following information:
|
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
Follow the steps in each section to configure OpenID Connect authentication for RapidIdentity.
From the Configuration menu, select Identity Providers.
From the Security section in the left menu items, click the caret to expand the Identity Providers menu and select Federation Partners.
From the Federation Partners workspace, select OpenID Connect from the Add Federation Partner selector.
In the Create New OpenID Connect Partner window, enter the required information. Refer to the below table for details.
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 |
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. NoteRapidIdentity only supports releasing LDAP attributes to OAuth 2.0 clients.
| |||||||||
OpenID Connect Configuration |
|
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.
From the configuration menu, select Identity Providers.
From the Security section in the left menu items, click the caret to expand the Identity Providers menu and select Federation Partners.
From the Federation Partners workspace, select WS-Federation from the Add Federation Partner selector.
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.
Click Save to add the WS-Federation Partner.
A confirmation message will display at the top of the page.
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.
Field | Description | ||
|---|---|---|---|
General |
| ||
Configuration |
| ||
Attribute Release - Name Identifier |
| ||
Attribute Release - Attributes |
Assign attributes by clicking the +Add Attribute
| ||
WS-Trust Configuration |
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.
|
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.
| ||
SAML Audiences & ReplyTo Urls |
|
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:
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.
Create a new Service Provider Configuration for RapidIdentity. The Identity Provider's metadata will be required during this step.
Ensure that the Service Provider Entity ID is a unique value.
Provide the IdP logout URL
Set up RapidIdentity as a Relying Party for the Third-party IdP.
Assign the new Service Provider configuration to RapidIdentity.
Create a New Service Provider Configuration for RapidIdentity
When integrating with a third-party IdP, RapidIdentity must be configured to be a Service Provider.
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.
Log in to the RapidIdentity portal as an Administrator and access the Service Providers section from the Configuration workspace.
Click the Register Service Provider+ button.
The Register Service Provider window will open.
Hover over the question marks (?) for additional information on completing the fields and for an example.
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.
After entering the required information, click Save.
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.
Release the idautoID value:
The IdP instance must be able to communicate with a datastore that contains the idautoID attribute, such as an Active Directory DC.
Must be released as "idautoid" (case-insensitive) or "urn:idauto.net:saml:attribute:idautoID".
Release the unique email address:
RapidIdentity is required to have the same value provisioned in its backing directory where 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 and the first one which uniquely identifies a User will be accepted.
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.
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.
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.
Close all browser sessions.
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.
Configuring the Claim Issuance Policy
Configuring the Release of the idautoID
Configuring the release of the unique Email Address
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.
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.
Log in to the RapidIdentity portal as an Administrator and access the Service Providers section from the Configuration workspace.
Click the Register Service Provider+ button.
The Register Service Provider window will open.
Hover over the question marks (?) for additional information on completing the fields and for an example.
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.
Export the Service Providers' metadata.
After entering the required information, click Save. The RapidIdentity service provider will be listed in the workspace and can be assigned applications for login.
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.
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.
Log in to ADFS and navigate to the ADFS Management application.
Click Relying Party Trusts and choose Add Relying Party Trust... to launch the wizard.
Click Claims aware
Claim tokens are issued by the IdP after authenticating the user. The login for the application will be the Service Provider, RapidIdentity.
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."
In the Choose Access Control Policy step, select Permit everyone.
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.
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."
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
In ADFS Management, navigate to Claim Description and choose Add Claim Description.
Enter the required values. Below is a sample of values to be entered.
Table 82. Claim Description ValuesField Name
Value
Display Name
IDautoID
Short Name
idautoID
Claim Identifier
idautoID
Description
<blank>
<Publish this claim description...>
<both boxes unchecked>
Navigate to Relying Party Trusts and choose the "RapidIdentity" relying party. Select Edit the Claim Issuance Policy.
Click Add Rule....
Choose the Send LDAP Attributes as Claims claim rule template.
Name the Claim rule similar to "Send IdautoID."
Choose the Active Directory attribute store.
Map the "IdautoID" LDAP Attribute to the "IdautoID" Outgoing Claim Type.
Click Finish and then OK to finish editing the Claim Issuance Policy.
Configuring the release of Email Address
Navigate to Relying Party Trusts and choose the "RapidIdentity" relying party.
Click Edit the Claim Issuance Policy.
Click Add Rule.
Chose the "Send LDAP Attributes as Claims" claim rule template.
Name the claim rule similar to "Send Email Address."
Choose the Active Directory Attribute store.
Map the E-Mail-Addresses LDAP Attribute to the E-Mail Address Outgoing Claim Type.
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.
From the Portal Module Selector, choose Configuration. Then in the Security menu, choose Identity Providers.
From the Left Menu Items, select Web Template.
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.
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.
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.
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.
 |
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.
 |
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:
From the Module Selector, click Configuration. From the Security section, click Identity Providers.
Click External Auth Realms from the left menu items.
Click Create Realm.
Table 83. Create External Authentication RealmField
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
To add external or internal attributes, under Attribute Map Items, click Add Item.
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.
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.
 |
A pop-out window will open with form fields. On the General tab, enter the information as provided by the identity provider.
 |
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.
 |