IDP Integration with cloud

Yesterday, we discussed about integrating an IDP with a membership directory. This article talks about integrating the IDP to the cloud.

The IDP integration with a cloud user pool is called identity federation. This is achieved by exchanging an artifact between the IDP and the cloud user pool using the Security Assertion Markup Language (SAML) which is a login standard that helps users access applications based on sessions in another context.

Just like the article on IDP integration with a membership directory, the first step involves the creation of a domain. When specifying a domain name, it must be checked that it is available.

The IDP will need to have a new application added such as the SAML Test Connector with one that is preferably responding with a signed response.  The consumer url validator as well as the consumer url must be provided.

Parameters will need to be added to the configuration. The default parameter is the SAML Name Id but a custom parameter will need to be added to the configuration which is the email address. This parameter will be included in the SAML assertion, and it will be easier for applications to locate and pass it through.

The SAML once setup correctly will be available via the issuer URL.  This is required to be specified as the metadata document URL in the cloud setup and establishes a reference to the SAML based identity provider aka IDP. 

A set of attribute mappings like those done between the IDP and the membership provider needs to be completed. In this case, the e-mail attribute would be mapped.

Finally, an application client will be added. Generally, application clients will generate client secret but nodeJs package manager aka npm clients will generate it instead so the checkbox must be left unchecked for application clients that use npm. The secure remote password protocol-based authentication must be configured as the authentication flow. An authentication flow that permits tokens to be refreshed will also need to be refreshed.

The application client settings will be specific to the enabled identity providers but generally, they include a set of URLs for sign-in and sign-out. If the authorization protocol is OAuth 2.0, the subset of flows such as implicit grant, authentication code grant, and client credentials will need to be selectively enabled. The scopes for these flows will include email and openid.

A successful integration can be tested with a validator that checks for the JWT token, access token, identity token along with the contact url.