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

[MatthiasWinzeler]

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?

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/145617739

The labels on this github issue will be updated when the story is started.

[sreetummidi]

@MatthiasWinzeler This is a valid ask and other customers have run into it. We will fix this in an upcoming version

[JohannesRudolph]

I think this a great fit now that work has started on #532

Will this be scheduled for 4.4 as well?

[jhiemer]

+1

[james-b-thomas]

We are also facing the same issue.

[ebertmi]

Any update on this?

[DennisDenuto]

There has been a 'idp discovery' feature pushed onto develop that address this issue. See https://www.pivotaltracker.com/story/show/155403107

There is currently an edge case bug. The idea is for this to be available ideally next release.

[MatthiasWinzeler]

@DennisDenuto Great to hear! To achieve my desired behavior in the initial issue report (i.e. default redirect to external IDP but local users still possible), will I need to set the login_hint or is setting config.defaultIdentityProvider sufficient?

[tack-sap]

For the 99% case you just need to set the config.defaultIdentityProvider - every request to the login page is then redirected to the external provider configured as default.
When you want to login with the internal user store (or any other configured IdP) using the UI flow you then need to pass the login_hint with your request.

As you say your internal users don't use the UI flow: When you want to login via the CLI (or retrieve a token directly via password grant) and your default idp does not support password grant (which is the case for you, as you write you are using SAML) nothing changes - if the default IdP does not support password grant we fallback to using internal/ldap idp.

Note that the default identity provider configuration is not contained in any release yet, but will probably be included in the next release.

[MatthiasWinzeler]

@tack-sap Sounds like it solves our issue in a very elegant way. Many thanks for respecting this use case! Will close this issue once it's released and tested.

[MatthiasWinzeler]

@tack-sap So I tried out setting config.defaultIdentityProvider to our saml IDP, but it breaks CF CLI login:

CF_TRACE=true cf login -a https://api.lyra-836.appcloud.swisscom.com
API endpoint: https://api.lyra-836.appcloud.swisscom.com

REQUEST: [2018-09-19T15:16:07Z]
GET /v2/info HTTP/1.1
Host: api.lyra-836.appcloud.swisscom.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.37.0+a40009753.2018-05-25 / linux



RESPONSE: [2018-09-19T15:16:07Z]
HTTP/1.1 200 OK
Connection: close
Content-Length: 731
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=utf-8
Date: Wed, 19 Sep 2018 15:16:07 GMT
Expires: 0
Pragma: no-cache
Server: nginx
Strict-Transport-Security: max-age=16070400; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Vcap-Request-Id: 2b42659e-24f7-4302-5b8b-c420e167b06f::35fdebe9-5697-4ea4-845b-1c0dc7a1863d
X-Xss-Protection: 1; mode=block

{"name":"","build":"","support":"https://developer.swisscom.com/contact","version":0,"description":"Cloud Foundry provided by Swisscom","authorization_endpoint":"https://login.lyra-836.appcloud.swisscom.com","token_endpoint":"[PRIVATE DATA HIDDEN]","min_cli_version":"6.32.0","min_recommended_cli_version":"latest","app_ssh_endpoint":"ssh.lyra-836.appcloud.swisscom.com:2222","app_ssh_host_key_fingerprint":"26:9c:7a:cf:02:77:aa:75:ac:80:ea:e5:68:de:d2:d0","app_ssh_oauth_client":"ssh-proxy","doppler_logging_endpoint":"wss://doppler.lyra-836.appcloud.swisscom.com:443","api_version":"2.122.0","osbapi_version":"2.14","routing_endpoint":"https://api.lyra-836.appcloud.swisscom.com/routing"}

REQUEST: [2018-09-19T15:16:07Z]
GET /login HTTP/1.1
Host: login.lyra-836.appcloud.swisscom.com
Accept: application/json
Content-Type: application/json
User-Agent: go-cli 6.37.0+a40009753.2018-05-25 / linux



REQUEST: [2018-09-19T15:16:07Z]
GET /saml/discovery?returnIDParam=idp&entityID=login.lyra-836.appcloud.swisscom.com&idp=openam&isPassive=true HTTP/0.0
Host: login.lyra-836.appcloud.swisscom.com
Accept: application/json
Content-Type: application/json
Referer: https://login.lyra-836.appcloud.swisscom.com/login
User-Agent: go-cli 6.37.0+a40009753.2018-05-25 / linux




API endpoint:   https://api.lyra-836.appcloud.swisscom.com (API version: 2.122.0)
Not logged in. Use 'cf login' to log in.
FAILED
Error performing request: Get https://login.lyra-836.appcloud.swisscom.com/saml/login/alias/login.lyra-836.appcloud.swisscom.com?disco=true&idp=Passeport+IDP: stopped after 1 redirect

If I understood you correctly, the CLI should fall back to internal/ldap IDP since our SAML IDP does not support password grant. Is this fallback maybe broken?

[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!

[MatthiasWinzeler]

@tack-sap Thank you very much for taking care of this edge case!

[MatthiasWinzeler]

@tack-sap do you have any ETA on this? desperately waiting on it :)

[tack-sap]

Hi,

The story with the bugfix is accepted since October 1st and it is available the latest versions of UAA. So you should be able to use the whole setup by now ;)

[MatthiasWinzeler]

@tack-sap works flawlessly, thank you!