gcf authenticating directly to /oauth/login and bypassing custom authentication

[jmprice]

the gcf client is passing credentials directly to uaa.config.AuthorizationEndpoint/oauth/token which is bypassing custom profiles like LDAP.

[scottruitt]

Hi Jon,

I have an existing story in our backlog to tackle this issue: https://www.pivotaltracker.com/story/show/60925130 It's a bit further out, is this something you're blocked on today?

Scott

[jmprice]

Hi Scott,

I wouldn't say it is blocking us, but since we do use LDAP authentication, we cannot have our customers use gcf until it is working. Until then, we can have them use the ruby version.

[scottruitt]

Thanks, Jon. We discussed it as a team today and have a good idea of what needs to be done. I also pulled it up higher in the backlog along with a block of login other stories. We should hit it in the next two weeks or so.

Scott

On Tuesday, December 3, 2013 at 9:48 AM, Jon Price wrote:

Hi Scott,
I wouldn't say it is blocking us, but since we do use LDAP authentication, we cannot have our customers use gcf until it is working. Until then, we can have them use the ruby version.

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

[jmprice]

That's great news! Thank you for pulling that in, I would really like to be able to direct people to use the new client.

On a side note, we went live with our new v2 environment today and our first 2 new customers created orgs which contain spaces in the name ( I hadn't considered testing that....) anyway, it works fine with the ruby client, but gcf doesn't like it at all. For now, we have renamed those orgs and put some validation in place to prevent people from doing that.

Jon

[jmprice]

Hi Scott, From looking at the backlog, it doesn't look like anyone has done anything with this. Do you have an updated ETA on when this may be implemented?

Jon

[scottruitt]

Hi Jon,

We should get to it in the next two or three weeks. Need to point some more stories above it in the backlog to know for sure.

Scott

[maxbrunsfeld]

Hi @jmprice,

Can you tell us the output of cf curl /v2/info? I ask because it sounds like your cf is making requests to the wrong URL- the UAA instead of your login server. cf uses the /v2/info API to determine the URL of the login server. Thanks!

• max, @khwang1 and @scottruitt

[jmprice]

Hi Max,
I'm pretty sure we have the correct endpoints being published.

cf curl /v2/info
{"name":"vcap",
"build":"2222",
"support":"http://foo.bar.com/display/PaaS/Home",
"version":2,
"description":"My Platform as a Service",
"authorization_endpoint":"https://login.paaslab1.foo.bar.com",
"api_version":"2.0.0",
"logging_endpoint":"wss://loggregator.paaslab1.foo.bar.com:443",
"user":"02cf78ca-caab2-417b-9a7a-a6474025747d"}

Jon

[webandtech]

@jmprice We delivered this fix in master. Would you be able to download the edge binary and try it out? Thanks!

[tjarratt]

Closing for now, please re-open if we haven't successfully resolved this issue @jmprice.

[jmprice]

The new code does now go to login and is getting the prompts, but it doesn't go to /oauth/authorize which is where the ldap authentication takes place. I can send you the output of the login.log for a request from the ruby cf client which is working correctly and the go cf client if that would help.

-- Jon

[karlkfi]

@jmprice Are you still having this issue? If so, can you open a new issue with details?

[jmprice]

Hi Karl - this is most certainly still an issue which is preventing us from moving to the new client. It is in the pivotal tracker at https://www.pivotaltracker.com/s/projects/892938/stories/66626492 but there has been no progress on it.

[khwang1]

Hi @jmprice, we're finally working on this issue. Can you send us the ruby cf client's login.log? That would help us to debug this issue.

Thanks!
Karen & Anand

[jmprice]

Hi Karen,

Attached are the logs from a ruby cf request and a go cf request.

-- Jon

[jmprice]

Apparently github will only let me attach images and not text files. How would you like for me to send you the log files?

[XenoPhex]

Hey @jmprice we're pretty sure that this was fixed by the UAA / Login Server team and that this works with the go cli as of CF Release v172. Would you mind if we closed this issue? Feel free to re-open if this still doesn't work for you or if there's anything else should discuss.

We're sorry it took us so long to resolve this.