Date
1 - 11 of 11
enable 2fa for UAA zone
|
JohnG
Greetings.
I hope this mailing forum can give me pointers on the following How to enable 2fa (but-in google-authenticator) for UAA (base and default zone)? After creating a 2fa provider, when I try to update UAA zone via curl/api post with update setting mfaconfig etc. I don't see any response back (yes, with right admin client access token) Also when directly updated the database query on identity_zone, config, when it reboots it restores mfaconfig enabled to false. Is there something 'am missing ; appreciate any pointers on this Thanks CG -- Sent from: http://cf-dev.70369.x6.nabble.com/ |
|
|
|
Dr Nic Williams <drnicwilliams@...>
I think the UAA team deprecated or removed 2FA/MFA features. Nic -- |
|
|
|
JohnG
>I think the UAA team deprecated or removed 2FA/MFA features.
Not sure I am following the "why", to remove 2FA for UAA zone? Any documentation pointing to that would be much appreciated. Thanks Dr Nic! |
|
|
|
Dan Beneke
Hi CG - The 2FA/MFA feature still exist in the most recent versions of UAA, but Dr. Nic is correct in suggesting that our intent is to remove it. We see the UAA more frequently used as an identity proxy than as an IdP, and often the IdP feature is used to store service accounts over actual human users that would be able to interact with 2FA/MFA flows. The predominance of this usage pattern has led us to consider viewing UAA on a path to become a stronger identity proxy tool wherein the user brings their own identity (IdP). This suggests 2FA/MFA features would/could be applied to the external IdP and not to the UAA itself as it would only be acting as a proxy. Regards, Dan Beneke >I think the UAA team deprecated or removed 2FA/MFA features. |
|
|
|
Peter Burkholder
> We see the UAA more frequently used as an identity proxy than as an IdP
This may be true because UAA doesn't support MFA. cloud.gov runs its own IdP simply because MFA is not supported by UAA. To quote from Bret Mogilefsky from https://github.com/cloudfoundry/cf-deployment/pull/540 > This is a shocking disappointment. The cloud.gov team predicated a chunk of their roadmap on the understanding that MFA was staying. |
|
|
|
Peter Burkholder
Sorry my response was so blunt. Product tradeoff decisions are always hard and you can't make everyone happy. Just wanted to let you know that there are consumers for this feature if you do revisit anytime soon.
|
|
|
|
JohnG
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? |
|
|
|
Enrique Cano
Hi Dan
Is the expectation then that we would integrate with the external IdP via SAML? Thanks Enrique |
|
|
|
Dan Beneke
Hi Enrique - Yes, either SAML or LDAP. CF supports connections to LDAP and SAML external IdPs. Regards, Dan Beneke On Tue, Feb 4, 2020 at 2:41 AM Enrique Cano <enrique.canocarballar@...> wrote: Hi Dan |
|
|
|
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 proxyThere 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 Thanks Dan and I also followed a bit the link that Peter provided on this. |
|
|
|
JohnG
Hi Dan,
Thanks for your feedback on this topic. I not sure the whitelisting (IP) solution would hamper growing UAA as IDP proxy? Both can co-exist (IDP and IDP proxy) and there is certainly a need as cloud.gov team mentioned. Further, an example is predix.io which was forked out of uaa (from my little understanding of what documentation is available) I understand it is resource-coupled, but technically doable :) Do we need a voting for this pull request? If the matters are beyond what are transparent here on the thread, we can close this topic. Good day, Thanks -CG -- Sent from: http://cf-dev.70369.x6.nabble.com/ |
|
|