Integration with Identity Provider (IdP) for Single Sign On - Rafay Product Documentation
Overview
In addition to managing users, groups and roles locally in the Org (Tenant), system admins can also optionally integrate their Org with their corporate Identity Provider (IDP) via SAML 2.0 or OpenID Connect (OIDC).
The SSO based login process validates the user's credentials against the corporate user directory typically managed by your Identity Provider (IdP). A successful validation ensures that users can log on to Web Console without the need for a separate login.
The integration with SAML 2.0 IdPs supports both IdP-initiated and SP-initiated flows. OIDC-based authentication follows a token-based flow managed by the configured IdP.
Important
Only privileged users with the System Admin role are authorized to view, configure and manage this setting.
Rafay Logo for IdP Chiclet
Click the button below to access Rafay's official brand assets. You can download images that you can configure as the logo in your Identity Provider (IdP).
Note
The OIDC authentication method currently supports Ping, Okta, and Keycloak as Identity Providers (IdPs).
How SSO Works
The controller supports SSO by implementing federated authentication using SAML 2.0 and OpenID Connect (OIDC).
To enable SSO, an Org administrator (highest privilege in the Org) must configure the Org to work with their Identity Provider (IdP). The IdP maintains a record of all usernames and their passwords in an encrypted format.
However, if you use a preconfigured IdP or if this is a subsequent login, the controller uses SAML assertions in an HTTP POST profile to communicate with your IdP.
For every login attempt, the Web Console sends SAML requests to the configured IdP login URL. The IdP validates the SAML request and sends a SAML assertion back to the Web Console.
Service Provider Initiated Flow
With the SP initiated flow for Single Sign On, the user accesses the Controller first and is redirected to the configured Identity Provider (IdP) for authentication and optional authorization. If the user is associated with multiple Orgs (tenants), the user is also asked to specify the Org name that they wish to access. The resulting assertion is then forwarded to the controller which uses the provided details to calculate the user's role.
| Identity Provider | Controller | User | |
|---|---|---|---|
| SSO enabled for Org(s)? | Authenticate User | Redirect User to Controller | Map Group to Roles |
| Access Org(s) | Provides Org name if associated with multiple Orgs | Redirect User to IdP | User Credentials |
| Send Assertion & Group Info | IdP Assertion | Provide Role based Access |
IdP Initiated Flow
With the IdP initiated flow for Single Sign On, the user accesses the Identity Provider first where authentication is performed. When the user clicks on the app, the user is redirected to the controller by the IdP. An assertion is forwarded to the controller which uses the provided details to calculate the user's role.
| Controller | Identity Provider | User | |
|---|---|---|---|
| User Authenticated | User redirected to Controller | Group mapped to Roles | Access App in IdP |
| Assertion with Group Info | Access Org | Role based Access Provided |
User Experience with SSO
Once the user enters their email address in the Web Console's authentication window, the Controller automatically determines whether Single Sign On (SSO) is configured or not.
Local Authentication
User experience when SSO is not configured and authentication is performed locally by the Controller.
SSO based Authentication
User experience when SSO is configured/required for the user. Authentication is performed by the Identity Provider (IdP).
Considerations: Same IDP configured for multiple Orgs
Create multiple applications within the Identity Provider with each application mapping to an Org that the IDP is associated with. Refer to the relevant Identity Provider section for more details around the set-up process
IDP initiated flow will remain the same
For the Service Provider initiated flow, there will be an additional step where the user has to provide the Org name
API Keys
In addition to browser based access to the Console, users can also access the platform via the RCTL CLI and REST APIs. Access to these channels is secured via a combination of "API Keys" and "Secrets".
Refer here on how to manage API Keys.
Supported NameID Formats (SAML)
Ensure that you use the "email address" for the SAML 2.0 NameID in your IdP.
Supported IdPs
The Web Console can be integrated with any SAML 2.0 compliant IdP. The table below describes the type of support for the ecosystem of IdPs.
Note: The following IdP classifications apply to SAML 2.0 integrations.
| Type | Description |
|---|---|
| Certified | A certified IdP is fully tested by the QA team. We certify these IdPs and perform regular testing with every release to ensure the SSO functionality works as expected |
| Supported | A supported IdP is not tested by the QA team with every release. However, the SSO functionality should work as expected and we will provide support for such IdPs |
Certified IdPs
Supported IdPs
- Any IdP that supports the SAML 2.0 protocol
Note Please contact Support for assistance with configuration of an IdP not listed under Certified IdPs.
IdP Metadata
For SAML 2.0–based integrations, some Identity Providers (IdPs) do not support the convenience of an IdP metadata URL for a streamlined initial configuration. For these situations, we provide the option for administrators to upload the "IdP metadata XML file".
IdP Users
Administrators can view the list of users that have accessed the Web Console using Single Sign On (SSO).