Authentication and Single Sign-on configuration
This page contains third-party references. We strive for our content to always be up-to-date, however, the content referring to external vendors may change independently of Omada. If you spot any inconsistency, please report it to our Helpdesk.
Here, you can find the guidelines for setting up Single Sign-On (SSO) connections via OpenID and SAML for a number of identity providers (IdPs) within Omada Identity Cloud.
Using Single Sign-On with Omada Identity
With Single Sign-On (SSO), you can use a shared authentication process between the Omada Identity Portal and other web-based applications and systems.
The authentication process is done via an Identity Provider (IdP) and Omada Identity is a Service Provider (SP) that relies on the IdP to grant access to the Omada Identity Portal.
Omada Identity supports SSO via two protocols:
- OpenID Connect
- SAML 2
OpenID Connect uses a JSON Web Token for the exchange of authentication tokens. SAML uses an XML-based token.
In Omada Identity, the feature only covers SSO. Omada does not synchronize any attributes from the IdP or provision users or accounts from the IdP. This means you must create identities and users via an HR systemClosed or a similar type of directory before users can log in via SSO.
The user name provided by the IdP must match the existing user name in Omada’s user table. If you provide an email address, the user name in the email (before the @ sign) is used.
SAML and OpenID Limitations
The SAML and OpenID authentication in Omada Identity only supports authentication by the configured Provider(s) as configured by using the IdP metadata URL, and SAML and OpenID requests must be signed by one of the certificates in the provided metadata.
These constraints mean that Omada Identity supports neither requests signed with a trusted certificate (which is not in the metadata) nor requests signed by an IdP which is in federation with the configured IdP.