Radancy Single Sign-On

Single Sign-On, or SSO is a commonly used and virtually necessary method of electronically authenticating a user across multiple, distinct applications or systems. Radancy recommends all clients use SSO for user authentication in all Talent Acquisition Cloud customer-facing applications. Once integrated, Single Sign-On (SSO) enables users to access Radancy applications using their existing network credentials, eliminating the need for separate login information.

There are three roles in an SSO implementation: 

  • The Identity Provider (IdP): An identity provider is a service that stores and verifies a user identity. IdPs are typically cloud-hosted services. In the context of the Radancy Talent Acquisition Cloud, the IdP is managed by the customer. 
  • The Service Provider (SP): A service provider is a federation partner that provides services to the user. In the context of the Radancy Talent Acquisition Cloud, the Service Provider is the Radancy application the user wants to access. 
  • The User: This is the user of the application. The user's data is transferred between the IdP and the SP.

Radancy supports the SAML 2.0 protocol for SSO. When a user wants to log in to a Talent Acquisition Cloud application, a SAML request is generated either by the SP (e.g when a user goes to the URL for one of the Talent Acquisition Cloud applications) or by the IdP (when a user clicks on a link from within their company's internal portal). Typically the user is then brought to a login screen in the IdP. After logging in the IdP sends a SAMLResponse to the SP letting it know if the user has properly authenticated. The SP processes that request and allows the user to access the application. 

SSO can be used for either accessing applications in the Radancy Talent Acquisition Cloud or accessing an internal mobility career site. If a user wants to access a Radancy application, the user must first be provisioned in the Radancy Platform by Radancy Customer Support and given the proper permissions to access the application.

 

Implementation Process

For Employee Referrals SSO setup, visit this page

For Hiring Events SSO setup, visit this page

To implement SSO, the Identity Provider and the Service provider need to share their SAML Metadata. SAML metadata is an XML document that contains information necessary for interaction with SAML-enabled identity and service providers. The document contains URLs of endpoints, information about supported bindings, identifiers, and public keys. 

You can find Radancy's metadata here: 

The service provider and identity provider each need to configure their systems to recognize the metadata of the other system. Once the metadata is implemented on both sides, a user with a valid NameID is required to test the implementation to confirm that it is working as expected.
 

Frequently Asked Questions

What Identity Providers have you integrated with previously? 

We can support any IdP that supports the SAML 2.0 protocol. Clients that have done previous integrations have used Okta, PingFederate, and AzureAD as well as several others. 

Is there support for single logout (SLO) functionality? 

Yes, if a logout URL is provided in the SAML Metadata we can support SLO. 

Is there support for multi-factor authentication? 

Yes, multi-factor authentication is supported if it is managed by the Identity Provider. 

What is your preferred Name ID format? 

We can support any NameID format the IdP is configured to support. Customers will use email addresses or GUIDs. 

Do you support encrypted SAML responses? 

Yes, we can support encrypted SAML responses if required. 

Do you support signed SAML Auth Requests? 

We can support signed SAML Auth Requests but typically do not. There are configuration limitations with Okta and PingFederate that require configuration changes on the IdP side. 

Do you support "Just in time provisioning" for user accounts? 

We currently do not support Just In Time provisioning for user accounts. 

What binding protocols do you support? 

We support HTTP Post and HTTP Redirect bindings. We do not support HTTP Artifact binding. 

Can the client control the level of access a user has to your systems via SAML Assertions? 

No. Authorization is role-based and controlled by Radancy via an admin tool. 

 

 

Was this article helpful?
0 out of 0 found this helpful