Possibility to use one time passcodes for auth

[MatthiasWinzeler]

The CF CLI provides a way to log in with one time passcodes (received from the login server) instead of username and password: cf login --sso <url>
Details see CLI source

This is needed in SSO scenarios (where SAML federation is enabled on the CF login server).

This pull request extends the cf-java-client to allow authentication with these one time passcodes.
We need this to extend the Eclipse plugin, which currently does not provide a way to authenticate users in SSO scenarios (see cloudfoundry-attic/eclipse-integration-cloudfoundry#36).

Integration tests are basically passing against a default bosh-lite, although I had to make some hardcoded values configurable to get them passing.
I couldn't get the integration test checkByteManrulesAndInJvmProxyAssertMechanisms working on my env - can you check that it's not because of my commit?

Note: The newly added tests retrieve the passcodes from the login server they run against by simulating a browser login. This works well for a default CF instance (i.e. bosh-lite). When run against a non-default CF instance that does not offer a login server or passcodes, these tests might (gracefully) fail/be skipped.

[cfdreddbot]

Hey MatthiasWinzeler!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you've already signed the CLA.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/104184778.

[nebhale]

@MatthiasWinzeler Do happen to know how that OTP works? I'm guessing that that is simply the bearer token that gets passed on each request?

[MatthiasWinzeler]

@nebhale It is not the JWT bearer token that gets passed, but a different method of obtaining such a OAuth2 JWT token.

The CF UAA offers multiple ways to obtain a token for a user: most importantly, POSTing the username and password to UAA's /oauth/token endpoint. The cf-java-client already supports this.

But the UAA also offers the the possibility to POST a passcode to /oauth/token. This passcode can be retrieved by a user navigating to UAA's /passcode page in the browser; if the user is already authenticated there (i.e. by using UAA's browser based SAML federation), he sees a one time passcode which he enters in the client program. The client program (i.e. cli or eclipse plugin) would then exchange the passcode to an OAuth2 token which it can subsequently use to act on the users behalf.

So this is basically an option when the user can not enter username and password to authenticate (for example in SAML scenarios, when there are no passwords, but SAML assertions exchanged in the browser); it just get an OAuth token for an already existing UAA web browser session.

Unfortunately, there is little official documentation. You can look at the implementation of the cf cli which implements this as a client program:
https://github.com/cloudfoundry/cli/blob/d6c2531718002c2074a6c1e557d34de16e47f7a8/cf/commands/login.go#L128

Or at the UAA code which does the server side lifting:
https://github.com/cloudfoundry/uaa/blob/bbea63986bbf2de9c42f231668e344a4a321184c/common/src/main/java/org/cloudfoundry/identity/uaa/login/PasscodeAuthenticationFilter.java

[nebhale]

Yup, got it. Just chatted with the UAA team and we'll definitely do this work in V2. You can track its progress here. Since this was opened against the V1 branch, where we will not be making changes I'm going to close this out. If you'd like to see it re-opened, please comment on the issue and I'll reopen it.

[MatthiasWinzeler]

Hi Ben
Could you merge it to v1 nevertheless?

Because we are right now extending the CF eclipse plugin to allow login with otp passcodes; and it is based on this change in cf-java-client. You can find our efforts here: https://github.com/pecko/cft (almost finished).

At the moment, we use the cf-java-client.jar from my fork; but since we'd like to merge the extended CF eclipse plugin back into the mainline, it would be nice if the used cf-java-client is from the mainline as well.

Is that possible?

[nebhale]

Does the fact that the Eclipse plugin will shortly be ported to use the V2 line change things at all?

[MatthiasWinzeler]

Will the new eclipse plugin (that is based on the v2) offer SSO login with passcodes?
If so, there would be no need in merging this request. Otherwise, it would be great if we could merge our eclipse plugin extension.

[nebhale]

@MatthiasWinzeler In my mind the answer to that is yes. However @aclement is the final word on that.

[MatthiasWinzeler]

@aclement Can you confirm that the SSO passcode login will arrive with the new eclipse plugin version?

We'd like to avoid being stuck on our custom eclipse and not being able to upgrade to the new eclipse plugin because we're depending on the SSO feature.

[aclement]

Hey. Nieraj and I were talking about this over the last couple of days.

Yes, it will be in a future version, I'm just not sure when yet. We want to jump on the v2 client as soon as it is capable. There is an imminent CFT release and that is not based on v2 of the java client, but still v1. We're hoping the CFT version for Mars.SR2 (where the CFT project will be on the eclipse 'train') will use v2 (perhaps a milestone), that SR2 is in March.

We have similar problems ourselves with deficiencies in V1 (ssh handling) but we think we'll be able to host that code in CFT for now whilst waiting for the v2 java client library to support it. I presume that kind of solution can't work for you as you need to fiddle with the core of the java client library as part of solving this problem.

If, at the point we jump on v2, you can shape the enhancements required in CFT, that'd make a great pull request to the project.

[MatthiasWinzeler]

Thanks for your answer @aclement !
I think we'll stick with our custom build of the eclipse plugin until the plugin based on v2 is available and look at merging then.

Is there any roadmap/pivotal tracker project where we can see upcoming changes in CFT (that we would eventually have to backport to our custom build)?

[aclement]

With the move to be an Eclipse project, I think it would be bugzilla entries for bugs/feature tracking work and something on the project roadmap page when they get around to fleshing that out (hopefully soon) - that page would pull together lists of bugs into themes for delivery in a release. You could probably watch bugs on the CFT tracker at eclipse bugzilla to see any activity.

[MatthiasWinzeler]

Thanks, I will watch that!