Date
1 - 4 of 4
Different behaviour in Login with Pivotal and Bluemix
|
Juan Antonio Breña Moral <bren at juanantonio.info...>
I am doing some tests to get the token required in any operation using CF API and yesterday, I noticed a difference between the login process in Pivotal and the same process in Bluemix.
CF API in Pivotal: https://api.run.pivotal.io/v2/info has defined a URL to get token: "token_endpoint":"https://uaa.run.pivotal.io" and Bluemix has the same behaviour: https://api.eu-gb.bluemix.net/v2/info "token_endpoint":"https://uaa.eu-gb.bluemix.net" In Pivotal and using local instance from CF, it is possible to authenticate with the URL: https://uaa.run.pivotal.io/login but in bluemix: http://uaa.eu-gb.bluemix.net/login I can't do the same thing. Using the field: authorization_endpoint from: https://api.eu-gb.bluemix.net/v2/info "authorization_endpoint":"https://login.eu-gb.bluemix.net/UAALoginServerWAR" it is possible to get token but why in bluemix the auth process using the UAA is disabled or it is not running in the same way that other CF instances? http://uaa.eu-gb.bluemix.net/login Juan Antonio |
|
|
|
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 |
|
|
|
Matthew Sykes <matthew.sykes@...>
Now that I've had a cup of coffee, I should clarify that the links may not
be present in future deployments so if you're looking to redirect to a graphical page, you may not be able to do that directly. You may also run into deployments that have not changed the default link values so they point to the wrong target... Perhaps what you really want to pursue is the use of the OAuth based flows and register your application so clients will automatically be redirected to authenticate and approve your application to act on their behalf. If you go with that mechanism, you'll be in line with everything else. On Wed, Oct 21, 2015 at 6:42 AM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote: Because Bluemix, like many other installations, uses a custom login server -- Matthew Sykes matthew.sykes(a)gmail.com |
|
|
|
Juan Antonio Breña Moral <bren at juanantonio.info...>
Hi Matthew,
many thanks for the technical explanation. In my tests, I discovered that at the moment it is compatible to get access using this field: "authorization_endpoint":"https://login.run.pivotal.io" "authorization_endpoint":"https://login.eu-gb.bluemix.net/UAALoginServerWAR" Cheers Juan Antonio |
|
|