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 which 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.
Read more about the configuration of AD FS 3.0 on Windows Server 2012 R2
OIDC Federation
Open ID Connect (OIDC) is a 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 | |
OIDC (based on OAuth 2.0) |
In our case OIDC federation creates a 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 an the external Identity Provider. |
|
client secret | A secret to create trust between Okta an 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 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 fill them later. As with all federations the email addresses should be stored 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. | Markus |
(Requested) Attribute | lastName | Last name of a user. It will be synced to Okta. | Neuy |
(Requested) Attribute | Unique email address of a user. It will be synced to Okta. | ||
(Requested) Attribute optional | 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. |
|