Re: Different behaviour in Login with Pivotal and Bluemix


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
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
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(a)gmail.com


--
Matthew Sykes
matthew.sykes(a)gmail.com

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.