This article provides information about Identity Providers and Protocols used in authentication and authorization systems. It covers common Identity Providers, OIDC Federation, and SAML Federation, along with their key components and configurations.
Pre-requisites for a successful connection to an existing IAM/SSO solution are that the existing IAM/SSO solution is capable of connecting apps via SAML 2.0 or OpenID connect and is publicly available (and not just in your internal network/infrastructure).
Identity Providers
A list of Identity Providers that are commonly used across our customer base:
- Azure AD B2C
- Okta
- Azure AD
- Active Directory + ADFS
Products/services that support the required protocols OIDC Federation or SAML Federation can be considered as well.
OIDC Federation
Open ID Connect (OIDC) is an authentication (and authorization) protocol that can be used to federate authentication. Therefore an OIDC IdP can be used to be federated with Okta.
| OIDC Spec | https://openid.net/developers/specs/ |
| OIDC(based on OAuth 2.0) | https://tools.ietf.org/html/rfc6749 |
In our case, the OIDC federation creates trust between Okta and an external OIDC IDP. Therefore Okta will send a specific group of users to the external IDP to authenticate and get a trusted result of that authentication containing some user information.
When using OIDC a discovery document (well-known) can be used to get the basic information about the authentication and authorization flows that are supported. It is usually publicly available as it only contains public information.
What values are used for our Federation and what do they mean?
Discovery Document (Source)
| What | Meaning | Example |
|---|---|---|
| token_endpoint | Endpoint to get new tokens for the different flows. In our case an endpoint to exchange a code for a token. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/oauth2/v2.0/token |
| authorization_endpoint | Endpoint to Authenticate/Authorize a user. A user will be send to that endpoint to authneticate. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/oauth2/v2.0/authorize |
| jwks_uri | Location where Keys for OpenID connect are stored. These keys might rotate. Therefore this document is not static long term. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/discovery/v2.0/keys |
| issuer | A value to validate who issued tokens. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/v2.0 |
| scopes | A number of “topics” that could be asked for during authentication. It will result in a number of claims (particular values) after authentication. | [“openid”,”profile”,”email”,”offline_access”] |
External Identity Provider (Source)
| What | Meaning | Example |
|---|---|---|
| client id | An ID to identify the connection between Okta and the external Identity Provider. | |
| client secret | A secret to create trust between Okta and the external Identity Provider. |
SAML Federation
Security Assertion Markup Language (SAML) is a standardized approach to solve authentication, authorization, and federation of identity. It is an XML-based protocol that comes with more freedom but also more complexity than protocols like OIDC.
For more information see:
Glossary for SAML
IdP: Identity Provider (external System)
SP: Service Provider (our federation Identity Provider – Okta)
In our case, SAML is only used for federation. Therefore it is only used for the connection from our Identity Provider (Okta) to an external Identity Provider. Specified groups of users will not authenticate at our Identity Provider directly but will be sent to the external Identity Provider using the SAML protocol.
In the federation scenario, our Identity Provider acts as a Service Provider (SP) federating the identities from an external Identity Provider (IdP). The connection is built by exchanging metadata information containing the mapping of the two services as well as security information like certificates.
Our identity solution – Okta – is not capable of providing a route to metadata information – it has to be downloaded and shared in other ways. External Identity Providers have to provide an email address. Configuring the Service Provider might be a multi-step process – it might also include putting dummy values in the Okta configuration and filling them later. As with all federations, the email addresses should be stored in lowercase.
What metadata information is important in the current case:
| Source: SP Metadata/ IdP Response | What | Meaning | Example |
|---|---|---|---|
| (Requested) Attribute | firstName | First name of a user. It will be synced to Okta. | John |
| (Requested) Attribute | lastName | Last name of a user. It will be synced to Okta. | Doe |
| (Requested) Attribute | Unique email address of a user. It will be synced to Okta. | john.doe@questback.com | |
| (Requested) Attributeoptional | mobilePhone | Mobile phone number of a user. It will be synced to Okta.Currently this value is not used. But if it is sent it should be a valid value. | 12345-56780907 |
| NameID | The NameID has to be an unique email address of the user. The user will receive security information via this email address. |
FAQ
What are the pre-requisites for connecting to an existing IAM/SSO solution?
The existing IAM/SSO solution must be capable of connecting apps via SAML 2.0 or OpenID Connect and be publicly available (not just in your internal network/infrastructure).
What are some commonly used Identity Providers?
Common Identity Providers include Azure AD B2C, Okta, Azure AD, and Active Directory + ADFS.
What is the difference between OIDC Federation and SAML Federation?
OIDC Federation is based on OAuth 2.0 and is generally simpler to implement, while SAML Federation is an XML-based protocol that offers more flexibility but can be more complex.