Identity Federation (SSO) Integration

Overview

Identity Federation is a method of access control between multiple related but independent systems.   Identity Federation can give customers greater control over their users’ access to the RiskIQ Platform. RiskIQ now offers Identity Federation as a premium add-on to your RiskIQ service, which simplified your users’ access to the RiskIQ Platform, and gives customer administrators rapid deprovisioning capabilities.  

By default RiskIQ uses PingIdentity’s Identity as a Service (IaaS) solution to manage user credentials. This offers strong protection for our customers’ credentials and reduces the risk of somebody successfully attacking our credential management system. The RiskIQ Identity Federation implementation allows clients to be signed into the RiskIQ application suite using the same credentials as their local network, in place of our standard username/password authentication. With Identity Federation, no password information is transmitted across the network to RiskIQ. Only the user’s identity is transmitted, digitally signed and encrypted using standard digital certificate technologies. 

This document details RiskIQ’s Identity Federation implementation. Customers must have implemented an interoperable Federated Identity solution within their network in order utilize RiskIQ Identity Federation.  Please review the Federated Identity Options section below for further information.  Contact your RiskIQ Sales or Customer Success team member in order to review pricing and begin the Identity Federation setup process.

Federated Identity Options

Protocols Supported

The RiskIQ SaaS Identity Federation solution currently supports the following Federated Identity Protocols:

  • SAML 2.0 (preferred protocol)
  • OpenID Connect 1.0

Note: RiskIQ supports Service Provider (SP) or Identity Provider (IdP) initiated SSO.  

Systems Supported

Although SSO should work with any Federated Identity system that supports SAML 2.0 or OpenID Connect 1.0, each product interprets technical specifications differently. 

The following systems have been verified as interoperable with the RiskIQ SSO Solution and are fully supported. 

  • Ping Identity PingFederate
  • Okta Identity Federation
  • CA Siteminder

Other products will likely be interoperable but support is not guaranteed.

Multi-Factor Authentication

RiskIQ does not directly support Multi-Factor Authentication (MFA) at this time.  However, many Identity Provider applications do support MFA solutions, so MFA may be required by the partner prior to passing the identity to RiskIQ.  Since Federated SSO is the only method of sign-on allowed for clients who have chosen to take advantage of this solution, customers may enforce a MFA requirement in this manner.  

Federated Identity Setup

Metadata

Typically, most systems can import and export metadata files between platforms. RiskIQ usually provides the URL to retrieve the RiskIQ metadata file so that the client can import the file and send theirs in exchange. The metadata file contains the signing/verification certificates and claims data available.

Required Claims

RiskIQ offers multiple options for passing user credentials from the customer Identity Provider to the RiskIQ Platform.  The preferred claim type is the E-Mail Claim.  

The E-Mail Claim Type

This type will map to the email address on file for the user within the RiskIQ application.  It is required to be the user’s email address within the customer’s namespace, and is required to be unique within our system.

The following format may be used for the email claim within the assertion:

<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="Email Address" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" /> 

Alternative Claims

If the customer does not wish to utilize the E-Mail Claim Type, the RiskIQ Platform can map from a customer-provided unique ID to a RiskIQ Account.  This attribute can be agreed upon at integration time, but will require management within the application and may slow down the new user setup process.  

SP-Initiated vs IDP-Initiated SSO

The RiskIQ Identity Federation solution supports both SP-initiated and IDP-initiated SSO.

Logout  / Session Expiration Behavior

The RiskIQ SSO solution also supports Single Log Out (SLO), via the REDIRECT or POST mechanisms.  When the Identity Federation is configured, a SLO URL may be provided, either directly or as part of the metadata exchange.  When the user logs out of the RiskIQ platform, they will be redirected to this URL to close the session with the Identity Provider.  

Provisioning/Deprovisioning

The RiskIQ SSO solution does not support automatic provisioning at this time.  RiskIQ Platform users must be provisioned by our Production Operations or Customer Success teams, as per current processes.  

Because a user who is enabled for Identity Federation in the RiskIQ Platform is prevented from authenticating via any other mechanism, users who are deprovisioned or disabled in their customer IDP will no longer be able to access the RiskIQ platform, thus enabling automated deprovisioning of RiskIQ users.  

RiskIQ SSO

RiskIQ SSO Logon Process Flow

Below is a basic walkthrough of what happens when a user clicks on an SSO link to log on to the RiskIQ Platform.

  1. The user clicks a link that points to the RiskIQ Platform.
  2. The RiskIQ Platform checks for previous authentication.  If one is found, skip to step 8.
  3. The RiskIQ SSO system checks for a saved username.  If one is found, skip to step 5.
  4. The user is prompted to enter their username.  
  5. The user is redirected to the RiskIQ SSO System.  
  6. The RiskIQ SSO system checks for previous authentication.  If found, skip to step 12.
  7. The RiskIQ SSO system generates an Authentication Request and redirects the user’s browser to the customer’s IDP solution.
  8. The user is authenticated by the customer’s IDP solution.
  9. The user’s browser is redirected back to the RiskIQ SSO system with their Authentication Assertion (containing claims, certificate validation, and signatures).
  10. The RiskIQ SSO system validates the Authentication Assertion and creates a new session for the user in the SSO system.  
  11. The RiskIQ SSO system redirects the user to the RiskIQ Platform, along with an internal Authentication Token.
  12. The RiskIQ Platform contacts the RiskIQ SSO system and validates the Authentication Token.
  13. The RiskIQ Platform establishes a session for the user.  
  14. The user is allowed into the application.  

This entire process usually takes between 3-6 seconds.

If the user is following a deep link from a notification or email in the Platform, the deeplink value is captured in step 4 and placed in a cookie. When the user is directed to the RiskIQ application in step 13, the deep link value in the cookie is then placed back on the URL, and the user then ends up at the page referenced in the deep link.