1. Messages
  2. enable 2fa for UAA zone

Re: enable 2fa for UAA zone

Dan Beneke
 

Hi CG - 

Thanks for the information and context.  The case presented is similar in spirit to the conversation that occurred in PR #540 as noted earlier in this email by Peter.  Generally, 2FA enablement is made difficult because it currently applies to all authentications broadly. 

We don't currently see a path for reopening this ticket and our thoughts as to why fall into two buckets:
1. It furthers the use of UAA as an identity provider and we believe it more valuable to focus on UAA as an identity proxy
2. It extends the use of UAA's 2FA/MFA functionality, which we believe should be deprecated (or follow IdP functionality)

There is a world where you could imagine UAA's functionality being split into two separate deployments - one acting as a proxy, the other acting as an IdP.  In that world, the IdP portion could theoretically choose to maintain IdP-like features like 2FA/MFA. We aren't there yet, but with outcomes like that in mind, we want to ensure we aren't adding to the complexity of uncoupling UAA's IdP and proxy functionality sets.

Regards,
Dan Beneke

On Mon, Feb 3, 2020 at 4:00 PM JohnG via Lists.Cloudfoundry.Org <ci_98yr=yahoo.com@...> wrote:
Thanks Dan and I also followed a bit the link that Peter provided on this.

Definitely I can see use-case as proxy as well as IDP itself. 

Would it be possible to strike a middle path here, in the sense that based on filters and whitelist of IP CIDRs the operators/admins 
can configure to accept API calls without 2FA, while anywhere outside would accept users credentials with in-built 2FA. So that way the auto-tests would not break (eg within CF vPC or dev env which are typically pvt ip-ranges)

Is there a path for reopening of the mentioned/closed ticket?


 

Join {cf-dev@lists.cloudfoundry.org to automatically receive all group messages.