Option to automatically redirect to external IDP (SAML/OIDC)

In most of our UAAs, we have two different user origins:

• A federated IDP (i.e. SAML or OIDC) that is used by 99% of the users
• The internal UAA database for technical users (these are users that are used for automation purposes - i.e. CI/CD stuff; this is because it is hardly possible to automate the federated logins which rely on browser redirects)

We now face the problem that when the federated users log in (which is 99% of the cases), they see the UAA’s login form and need to click on the saml/oidc login link. This is not a nice user experience. We like to skip this step and redirect the users directly to the single configured external IDP since this is the path 99% of the time (also since the technical users almost never need to login using the browser and never use this login form).

We’re aware that if we disable the internal user management this automatic redirect happens. But this is not desired since we still want to use the internal database for the technical users.

We implemented an ugly workaround on the LB that sits in front of the UAA - it just redirects every attempt to /login to the respective SAML login link. This gets even worse since this SAML login link contains the entity id which can differ for each UAA (so we need to adapt the rule for each UAA).

So we would like to introduce a option to make this possible: either with something like defaultOnWebLogin: true that can be set on saml/oidc provider level or a global redirectToExternalIdp: true (that only redirects automatically if there is only one external idp configured). Or maybe extend the IDP discovery page that it automatically redirects if there’s only one external IDP?

It might sound like an edge case; but it’s probably how a lot of enterprise customers have configured their UAAs.

Would you welcome a PR that adds this option?

[tack-sap]

Hi Mathias, from UAA side the fallback does work when performing a password grant. However it seems that the CLI does not get to the point where it tries to perform a password grant, but gets a redirect to the IDP, when trying to get the login info from uaa. Looks like we missed this bug in combination with the CLI. I analyzed and created a bug for this: https://www.pivotaltracker.com/story/show/160650401

Thanks for reporting the issue!

[ebertmi]

Any update on this?