Using a hostname within the uaa.url causes misconfiguration of oidc .well-known endpoint.

[kansberry]

When setting the uaa.url to "https://172.31.75.4:8443", the OIDC .well-known endpoint produces a valid endpoint list with 8443 as part of each url (i.e. authorize, token, userinfo, etc). When uaa.url is specified using a hostname like "https://www.example.com:8443", the .well-known endpoint does not produce valid OIDC endpoints. For each, the hostname is present without the port number. My instinct is the uaa.url should not contain the port number and simply use the uaa.ssl.port concatenated to the uaa.url? Not sure on this part. Simply thinking out loud.

[cf-gitbot]

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

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

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

[aeijdenberg]

Perhaps worse, it seems that the output of the well-known config is based on the headers sent in the request. We found this issue when trying to debug a reverse proxy issue which resulted in the port numbers being swallowed in the well-known config.

Upon investigation we found that when we SSH into the instance running UAA, we could demonstrate the divergence of behaviour with a simple curl command:

# accessing via external hostname
curl -k https://concourse.example.com:8443/oauth/token/.well-known/openid-configuration

 {
     "issuer":"https://concourse.example.com:8443/oauth/token",
     "authorization_endpoint":"https://concourse.example.com:8443/oauth/authorize",
     "token_endpoint":"https://concourse.example.com:8443/oauth/token",
     ...
 }

# accessing via local hostname
curl -k https://localhost:8443/oauth/token/.well-known/openid-configuration

 {
     "issuer":"https://concourse.example.com:8443/oauth/token",
     "authorization_endpoint":"https://localhost:8443/oauth/authorize",
     "token_endpoint":"https://localhost:8443/oauth/token",
     ...
 }

Note that the issuer is correct in both cases, using the value we passed to uaa.url in our job config, however the authorization_endpoint (which is what the user is directed to), and the token_endpoint which is what applications need to connect to for exchanging tokens are completely broken.

The configuration output for the well-known endpoint should not be using any hostnames except that specified in the configuration.

We've been able to work around by mucking around a bit with headers from our reverse proxy in case that's helpful for others.

[cf-gitbot]

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

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

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