Once the original PR was merged we found a couple of problems that prevented this from working. These are fixed in this PR: FIXME
There's also a docs PR, which I am about to rework a bit: alphagov/paas-team-manual#104
CF v253 introduced a UAA change that appears to require a new tokenKeyUrl property to be set to allow Google's signatures to be validated. A bug exists for this upstream.
We didn't discover this before merging, as there are no automatic tests for the passcode login flow and I didn't think it necessary to manually retest following the upgrade, something that looks very foolish in hindsight.
It was unclear to me if or how UAA was validating the signatures from OIDC providers before this upgrade. Since it's quite troubling that there might have been no validation at all previously I spent a little time watching as David King tried to work out what was going on prior to upgrade. We established nothing conclusive, but he did point out that it's possible that this was somehow being configured via the Discovery URL https://accounts.google.com/.well-known/openid-configuration
The user visits login.domain/passcode to get a one-time code to use in the CLI, they then get redirected to /login, visit google to login and then return to access the passcode page.
This requires sticky sessions to be enabled on the UAA load balancer because the the URL that a user was intending to visit is saved in a server side session and there does not seem to be a way of sharing the sessions between UAA instances.
The expectation from the UAA team seems be to that it will be deployed behind gorouter, which automatically uses sticky sessions when it sees a JSESSIONID cookie. https://docs.cloudfoundry.org/concepts/http-routing.html We switched away from gorouter load balancing of UAA (and all CF endpoints) in #116974545
In order to fix this, an ELB stickiness policy has been defined, based on the UAA JSESSIONID cookie. I don't believe this will have any effect on most of our requests through the ELB, as most of them will be from the CLI.
It doesn't appear that CF acceptance testscover passcodes, or anything else that might validate that sessions are sticky. I've agreed with @alextomlins and @timmower that we will not add a test either of passcodes or stickiness, as it felt like this might delay fixing our admin accounts still further.
The new admin account email is currently flagged as spam by gmail because it is sent from a digital.cabinet-office.gov.uk email address and doesn't pass DMARC checks. This problem is likely to be because DMARC has been turned on for digital.cabinet-office.gov.uk. We also send emails to new users and for password resets from digital.cabinet-office.gov.uk via SES, so this is something we should investigate.
- (as before) #142062497 to fix the redirect_uri breakage
- add a test for sticky sessions / passcodes
- ensure that emails sent to users/admins via SES are passing DMARC/SKIM/SPF