Microcopy:

Review the microcopy Google Doc: 10850: [UI String] Generic developer portal SSO integration with third party OIDC IdP

References:

• See guidelines in the 3scale Microcopy Guide

Design review

Updated design[Feb 23]:
https://docs.google.com/presentation/d/1HceI3EXlgW8cO01mvcVOG-HoBjenPIGe3RIrm3aa7-g/edit#slide=id.g2b6e448c6ba_0_120 

Generic developer portal SSO integration with third party OIDC IdP

So far in order to perform SSO integration for developer/administration portal login we have 3.5 possibilities:

• RHSSO (done)
• Auth0 (done)
• Github (done)
• An existing customer is asking to add a fourth option in order to allow the integration with generic OIDC IdP.

Some examples of IDP most requested by customers are (in order of importance):

• Azure SSO (now called Microsoft Entra ID)
• Okta
• Ping Identity
• ForgeRock
• AirLock
• Curity 

------------------------

Dev note

This feature must be done onion-style, minimum amount first. The first layer of the onion (minimum deliverable product for the initial delivery) should be defined in broad strokes.

We will need the following:

The definition of this issue should involve somebody that has a good understanding of OAuth protocol, OIDC protocol and is:

• willing to gather which OIDC providers the customers want to integrate
• compare the different fields they provide and if it makes sense to add to our project

Things that need to taken into account

• integration into dev portal (should be the easiest, login page)
• integration into admin portal (login page)

We would probably need to have some generic fields like:

• name
• description
• icon?

Then dynamic fields to fetch the fields that we require, we need to know:

• email is validated
• email field
• username
• probably more...

The dynamic field implementation would probably be some dynamic rules, like in the mapping rules. (see keycloak)

------------------------

This feature must be behind a flag

Although RHSSO/Keycloak can be used as broker and bridge to the actual IdP provider behind, in case we really want to pursue such "generic" integration in Porta, we need to consider the following information configurable by the user:

• the name of the integration
• oauth endpoints/base urls
• scopes to request

We need also to get the fields required by our integration:

• email
• email verified
• organization name
• username

Those fields might differ from one provider to another, there may be no "generic" way of doing it. And the fields sometimes include some logic that should be evaluated.

See for example github client: https://github.com/3scale/porta/blob/027f534f49813dca087b69dde5dc369d73989af9/app/lib/three_scale/oauth2/github_client.rb

For generic integration, error handling needs to be really good.

Notes (not for engineering)
Once we have something in place we need to make sure it works with Azure SSO. We can contact <customer> to walk us through an Azure SSO setup. See comment from Thomas below.