inconsistencies login server to UAA after upgrade cf-171 to cf-180

[oliverro]

Hi All,
we have our own, dedicated login server running together with cf-171. Everything performed as designed.
We were studying the release history documentation in order to assess changes from cf-171 until incl. to cf-180. The only high-level changes found are:

• v178:
  • Login server v1.8.4
• v177:
  • Login server v1.8.3
  • UAA v1.8.1
• v175:
  • CF Security Groups are now released (?) impact to be assessed
• v172:
  • Bump Login Server to 1.6.3
  • Bump UAA to 1.6.5
    Looking closer at documentation of v177 UAA upgrade we did not see any changes/enhancements which should indicate that login server is now incompatible with the new UAA.
    Could someone from UAA team please help us to identify what might be wrong? I would be available via Email and/or phone in order to discuss things.
    Thanks in advance.

[rmorgan]

Hi @oliverro ,

Can you expand a bit on the exact problems you are seeing? There were some changes in the UAA 1.8.0 release to tighten security a bit on the /oauth/token endpoint (see: https://github.com/cloudfoundry/uaa/releases/tag/1.8.0) but without seeing exactly what issues you are seeing it's hard to pinpoint what may be going on.

cc @fhanik

[oliverro]

Hi, thanks for the reply ... I am Oliver by the way. ;o)

In our environment where this fails, the result of the curl (see below) is a 401 Unauthorized, with a www-authenticate challenge that says:
Www-Authenticate: Bearer realm="oauth", error="unauthorized", error_description="Bad Credentials"

There is also a response body:
{"error":"unauthorized","error_description":"Bad Credentials"}

curl: curl -k -v -H "Accept: application/json" -H "Authorization: bearer $TOKEN" -d "response_type=code&client_id=jtace&source=login&username=@&redirect_uri=https://ace.stage0.ng.bluemix.net:443/rest/oauth/callback" https://uaa.stage0.ng.bluemix.net/oauth/authorize

So we think that either the UAA interactions have changed in the build of cf-180, or perhaps the loginserver's OAuth client (called "login") isn't set up with the correct authorities.

login oauth client:
$ uaac client get login
scope: cloud_controller.admin oauth.approvals openid scim.admin scim.read
scim.write
client_id: login
resource_ids: none
authorized_grant_types: authorization_code client_credentials refresh_token
authorities: scim.read cloud_controller.admin uaa.resource scim.admin
oauth.login scim.write openid
autoapprove: true

(so looks similar like what we have in our other environment with cf-171)

jtace client:
$ uaac client get jtace
scope: cloud_controller.admin cloud_controller.read cloud_controller.write
openid password.write scim.read scim.write
client_id: jtace
resource_ids: none
authorized_grant_types: authorization_code client_credentials password
refresh_token
authorities: password.write scim.write scim.read openid cloud_controller.write
cloud_controller.read cloud_controller.admin
autoapprove: true

(also looks like the working one)

So what do you think with regards to change of the login server behavior in cf-177? (or better to say from cf-177 until incl. cf-180)? On the release notes we did not really see how the login flow should have changed. Any idea where we could start look into why it fails - like i.e. oauth?

Thanks in advance.

[fhanik]

/oauth/authorize needs a client_secret parameter

[ghost]

and yes, there have been some changes. some of these endpoint were a bit
too open not reading all required information.

On Friday, September 12, 2014, Filip Hanik notifications@github.com wrote:

/oauth/authorize needs a client_secret parameter

—
Reply to this email directly or view it on GitHub
#97 (comment).

[oliverro]

Ok, thanks. Could you please let me know where/how to obtain such a client_secret parameter?
Does this need to get passed into UAA, is it just returned from it?
Which UAA methods are affected?
Thanks in advance.

[fhanik]

hi @oliverro

your request

curl -k -v -H "Accept: application/json" -H "Authorization: bearer $TOKEN" -d "response_type=code&client_id=jtace&source=login&username=@&redirect_uri=https://ace.stage0.ng.bluemix.net:443/rest/oauth/callback" https://uaa.stage0.ng.bluemix.net/oauth/authorize

is referring to the client jtace. This client must have a secret defined in order for it to use the password grant.
You are required to provide the secret for that client.

https://github.com/cloudfoundry/uaa/blob/master/uaa/src/main/webapp/WEB-INF/spring/login-server-security.xml#L67-L91

The change you are noticing is that previously, the secret was not required, and this created a loophole, allowing the login server to bypass client authentication.

[fhanik]

See http://tools.ietf.org/html/rfc6749#section-2.3.1
where client_id and client_secret are required parameters

[sbweeden]

@fhanik I don't understand the comment about needing a client secret for jtace. The purpose of the loginserver is to obtain an authorization code, for another client, on behalf of another user. The loginserver should not need the client_secret of the jtace client. Instead the loginserver passes it's own access token (with the oauth.login authority, obtained using a client_credentials flow), and identifies that it is an all-powerful loginserver by way of the "source=login" parameter to the token endpoint.

Using curl examples, could you explain precisely what the flow(s) should be for a loginserver trying to obtain an authorization code on behalf of another client, for a resource owner that the loginserver has authenticated?

[sbweeden]

Because this issue has been marked closed, and I don't think it is closed, I've opened #98 to continue the discussion.

[fhanik]

@sbweeden - my mistake, i thought you were talking about a password grant - you are indeed talking about a authorization code grant.

[fhanik]

In 180 the UAA supports multiple origin's. The username is no longer unique. You have two options, one is passing the UID for the user or the username/origin combo

state=5pcSXI
client_id=app
response_type=code
redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fapp%2F
source=login
username=marissa
user_id=5fdcf183-e2c9-4abc-aa31-11bfcc8c3f3
origin=uaa
add_new=false

For your curl command, simply add the parameter origin=uaa

[sbweeden]

Thanks, that does work.

How, as a consumer of build 180, were we supposed to discover this change, and where can I find updated documentation on the new loginserver interfaces? If we've missed something obvious, I'd like to improve our process for where we look to understand new changes.

[fhanik]

URL: /uaa/oauth/authorize?client_id=app&redirect_uri=http://localhost:8080/app/&response_type=code&state=5pcSXI

Auth: Bearer eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJiNzY1ZTU4Yi03OWFlLTQ0N2UtOGViOC0zZGNiMGM4MmFiZTYiLCJzdWIiOiJsb2dpbiIsImF1dGhvcml0aWVzIjpbIm5vdGlmaWNhdGlvbnMud3JpdGUiLCJzY2ltLnVzZXJpZHMiLCJvYXV0aC5sb2dpbiJdLCJzY29wZSI6WyJub3RpZmljYXRpb25zLndyaXRlIiwic2NpbS51c2VyaWRzIiwib2F1dGgubG9naW4iXSwiY2xpZW50X2lkIjoibG9naW4iLCJjaWQiOiJsb2dpbiIsImdyYW50X3R5cGUiOiJjbGllbnRfY3JlZGVudGlhbHMiLCJpYXQiOjE0MTA4MDg3ODUsImV4cCI6MTQxMDg1MTk4NSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDgwL3VhYS9vYXV0aC90b2tlbiIsImF1ZCI6WyJzY2ltIiwib2F1dGgiLCJub3RpZmljYXRpb25zIl19.M9i9SKuPesOOAg4-pRfSCcpNY2ttjPHLe_3XVo3sXvE

Parameters: state=5pcSXI&client_id=app&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fapp%2F&source=login&username=marissa&user_id=5fdcf183-e2c9-4abc-aa31-a11bfcc8c3f3&origin=uaa&add_new=false

[fhanik]

@sbweeden - the source=login is not technically a public API that the UAA offers, so we don't have an official release process for it.
The easiest way to follow along would be to read the release notes.
https://github.com/cloudfoundry/uaa/releases/tag/1.7.2
This change was quite a while back ago. But you can always open issues here or post on the vcapdev mailing list.

[sbweeden]

How can you claim source=login is not public?

https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#trusted-authentication-from-login-server

What is public then?

The real problem is that message-level backward compatibility broke, causing significant delays in adopting a new CF build.

[fhanik]

It's an API we maintain specifically for the login-server that may authenticate users elsewhere. and hence we release those in sync.

We will update the docs. sorry for the inconvenience.

[sbweeden]

Thanks. We have written our own loginserver that uses this interface to UAA and it is important for us to understand that it is a supported and documented interface.