Re: Different behaviour in Login with Pivotal and Bluemix
Matthew Sykes <matthew.sykes@...>
Because Bluemix, like many other installations, uses a custom login server
to provide additional integration points and branding for its users. Not too long ago, login and UAA were separate jobs and vendors like IBM would deploy their own login server per a documented contract with the UAA. Then the UAA team decided to merge UAA and Login to make some things easier for the team to manage in the code base. When that merge happened, vendors could still deploy their own login server but there was no way to completely disable the one inside of the UAA. Instead vendors could simply advertise links to the custom login server. In addition to the fact that the login endpoint in the UAA cannot be disabled, it includes a fair amount of branding that can't be completely removed or replaced without forking the UAA so there are definitely some side effects. This topic has been raised with the Identity team a few times - most recently during the PMC yesterday. If you want those advertised links, you can hit the /info (or /login) endpoint on the UAA with an 'Accept: application/json' header: ``` $ curl -s -H 'Accept: application/json' https://uaa.eu-gb.bluemix.net/info | jq .links.login "https://login.eu-gb.bluemix.net" ``` That pattern should work across all providers. Hope that helps a bit. On Wed, Oct 21, 2015 at 4:06 AM, Juan Antonio BreƱa Moral < bren(a)juanantonio.info> wrote: I am doing some tests to get the token required in any operation using CF -- Matthew Sykes matthew.sykes(a)gmail.com |
|