Operator to enable 2FA/MFA on default UAA zone

[drnic]

New MFA support for UAA looks fantastic. This PR enables it for all CF users (prompted on their next login attempt via cf CLI or https://uaa.xxx visit.

MFA Code ( Register at https://uaa.cf-ohio.starkandwayne.com )>

Similar PR submitted to cloudfoundry/uaa-release#90

/cc @sreetummidi - do these PRs look right to you? Anything missing? (this is what I'm applying to my dev/test CF)

[cfdreddbot]

Hey drnic!

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

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/158482220

The labels on this github issue will be updated when the story is started.

[cf-rel-int-status-bot]

Hello friend, it looks like your pull request has failed one or more of our checks. Please take a look! 👀

[aeijdenberg]

@drnic - all users? Is it easy to carve out CI/CD users? (e.g. users created for deploying CF apps via CircleCI or Concourse pipelines)

[drnic]

@aeijdenberg I just learned about UAA MFA this morning from watching @sreetummidi cfsummit youtube video and then went off to figure how to enable it. Hence I've put this manifest in experimental folder.

@sreetummidi @jhamon @DennisDenuto how might CI/CD users avoid MFA? Is MFA ignored for cf auth CLIENT_ID CLIENT_SECRET --client-credentials?

[drnic]

@aeijdenberg btw, you can enable MFA for specific uaa identity zones; GE Predix ppl wrote a few things here https://forum.predix.io/articles/32639/multifactor-authentication-mfa-in-uaa.html

[drnic]

@sreetummidi @jhamon @DennisDenuto is there or will there be a way to make MFA optional; and to allow its enforcement or usage determined by client?

[jhamon]

If MFA is enabled, it will be applied during all user authentications. For the moment enabling it in your deployment will break any errands or smoke tests that are relying on user credentials, and anything else that uses cf login without a human present to perform the second factor authentication step.

We are currently working on a feature narrative to describe the implications of this change and help teams migrate from inappropriate use of user credentials in automation so that MFA security can be enabled without disruption. The solution is as you said, @drnic, to create a client_credentials client in the UAA and authenticate using those credentials via the new cf auth CLIENT_ID CLIENT_SECRET --client-credentials command.

There are no plans to allow opt-out from MFA protections if it is enabled in the UAA.

[heyjcollins]

Hey @drnic - thanks for submitting this PR. We're going to pair with UAA on the effort @jhamon mentioned in a previous comment and then determine course of action from there so going to pause on this for the moment. Cheers!

[aeijdenberg]

@jhamon - is it possible to make a UAA client a SpaceDeveloper in a single space? If not, then it's not an effective substitute for CI tasks.

ie we support many teams (each with their own space) deploying apps via CircleCI.

We've been creating dedicated CI users for each delivery team, adding them as SpaceDevelopers to the appropriate space.

We've then either supplied the username/password to the delivery teams, or in instances where we administer their CircleCI, we set as environment variables for their jobs.

It would be a huge step backwards if such a UAA client had full access to all apps, as clearly a developer with control over their own build pipeline (which ours all do) could leak the underlying credentials by echoing them as output in their build scripts, thus escalating their access to an entire installation, instead of being limited to their space, as they are presently.

Clearly we'd like to have MFA enabled for humans, but not for CI jobs, as it's not appropriate for that use-case.

On a related note, many of our human users login with SSO from G-Suite - we don't want UAA to do MFA for them, as it's already covered. Other users that are not in our G-Suite domain are the ones that we wish to require MFA for.

[sreetummidi]

@aeijdenberg @drnic You are absolutely right about not wanting to provide admin level privileges to all pipelines

We are in the process of doing the following

1. The CAPI team will provide enhancements soon for OAuth Clients to be associated with CF Roles like Space Developer.
2. We will removing dependency on CATS/smoke tests needing internal UAA User accounts

With the two changes above you will enable MFA for users but still use restricted OAuth clients for pipelines

[aeijdenberg]

Thanks @sreetummidi . Are we absolutely convinced that it's a good thing for resource servers (such as CAPI) to need to be aware of 2 namespaces of "users"? e.g. users and clients?

By way of comparison, Google's OAuth implementation gives their OAuth client email address identities (foo@bar.gserviceaccounts.com or similar) which means that their resource servers can reason about a single namespace of users for their access control requirements.

[sreetummidi]

CAPI does't need to distinguish between users and clients. For resource servers they rely on the sub field in the token. This could be a client id or user id. They don't need to distinguish. They will be able associate both with any further App specific role. In case of CC it could be something like a space dev

[jmcarp]

@sreetummidi: where can we track work on the two features you mentioned? Are there stories in pivotal tracker?

[sreetummidi]

@zrob @SocalNick Are there any stories open to track the work around CF CLI and CAPI supporting association of roles with UAA clients.

[SocalNick]

I chatted with CLI team, waiting to hear back: https://cloudfoundry.slack.com/archives/C032824SM/p1533163033000282

[aeijdenberg]

I thought of this thread when reading https://www.cloudfoundry.org/blog/cve-2019-3798/ earlier today. I remain pretty convinced that mixing entities (client and users) in what many systems will regard as the same namespace violates the principle of least surprise, and I'm pretty convinced this is the first of likely many subtle bugs that may creep in as a result.

Mind you I also recently learned several other things about UAA users that are perhaps equally surprising.

1. email verified is meaningless in UAA (ie it's set by default).
2. email address is not unique for users within UAA. There can be multiple users with a different origin set with the same email address. While each user does get a different GUID, any relying system which makes the assumption that UAA would only ever signed a JWT for a particular email address for a single user will be quite surprised.

[SocalNick]

cc @tnwang @aramprice @wc22222 @dbeneke

[Syerram]

UAA Team feedback: The MFA was offered as a beta feature a while ago but it never gained enough traction to go GA. Closing this PR because UAA does not intend to provide support for this feature.

FYI Dan Beneke.

[mogul]

This is a shocking disappointment. The cloud.gov team predicated a chunk of their roadmap on the understanding that MFA was staying.

[norman-abramovitz]

@SocalNick Where was the discussion about MFA not gaining traction?

[dbeneke]

It's an evolving topic. During presentation and discussion at CF Summit EU this month, UAA proposed their intent spend effort simplifying and modularizing UAA - and our belief that UAA should be moved toward identity proxy becoming its core function. As a part of this, MFA would follow the path of the modularized IDP functionality, or potentially lose support. Positioned as an identity proxy, UAA would become reliant on it's attached IDPs (LDAP, SAML, etc.) to offer and support MFA feature sets.

[SocalNick]

@norman-abramovitz you may have intended to mention @Syerram