1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
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?


 

Re: New lead for Community (CAB) meetings

Swarna Podila
 

Thank you, Troy.

Dear Community,
Here is a last call if anyone else would like to support Troy or nominate themselves to co-lead CAB with Troy.  The "call for nominations" will officially close at11:59PM US Pacific (it is still Feb 5th here in my timezone ;) ).

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.


On Wed, Feb 5, 2020 at 7:49 AM Troy Topnik <troy.topnik@...> wrote:
I'd be happy to take this on if nobody else is biting. I hereby nominate myself. :)

For those that don't know me, I am a Product Manager at SUSE responsible for SUSE Cloud Application Platform. I have been working in and around Cloud Foundry since 2011 as a technical writer, instructor, product manager, and enthusiastic user. I've recently been focused on Cloud Foundry incubator projects related to Kubernetes (Eirini and Quarks), and on the Stratos web user interface.

Huge thanks to Dr. Max for leading these meetings over the years! 
 
TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 
Re: New lead for Community (CAB) meetings

Dr Nic Williams <drnicwilliams@...>
 

Thanks Troy, that sounds awesome.

Thanks again Dr Max for many awesome years running CAB calls.

Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
cf-networking-release v2.28.0 & silk-release v2.28.0

Keshav Sharma
 

Hi cf-dev,

cf-networking-release v2.28.0 & silk-release v2.28.0 have been cut! 

Release Highlights

  • Application Developers now receive a 401 when using an expired access token, according to spec. details

Silk-Release v2.28.0

Release Highlights

  • Platform operators can expose UDP services running on the host, in the same way that TCP services can be exposed currently. details


CF-Bosh Networking
Re: New lead for Community (CAB) meetings

Troy Topnik
 

I'd be happy to take this on if nobody else is biting. I hereby nominate myself. :)

For those that don't know me, I am a Product Manager at SUSE responsible for SUSE Cloud Application Platform. I have been working in and around Cloud Foundry since 2011 as a technical writer, instructor, product manager, and enthusiastic user. I've recently been focused on Cloud Foundry incubator projects related to Kubernetes (Eirini and Quarks), and on the Stratos web user interface.

Huge thanks to Dr. Max for leading these meetings over the years! 
 
TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
IMPORTANT NOTICE: [dotnet-core-buildpack] End of Support for dotnet-runtime versions 3.0.x after 2020-03-03

Kashyap Vedurmudi <kvedurmudi@...>
 

The first release of the .NET Core buildpack after March 3, 2020 will no longer include dotnet-runtime versions 3.0.x. These .NET versions will no longer be supported upstream.[1] Please migrate your .NET Core apps to supported versions of dotnet-runtime before that time.


Note: Unless you are manually specifying a version of dotnet-runtime for the buildpack to use, or you have customized your .NET Core buildpack, no action is required.


As always, the buildpacks team is happy to answer questions you may have about this deprecation in the #buildpacks Slack channel.


[1] - https://dotnet.microsoft.com/platform/support/policy/dotnet-core


Thanks,

Kashyap Vedurmudi, CF Buildpacks PM
Re: enable 2fa for UAA zone

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

Is the expectation then that we would integrate with the external IdP via SAML?

Thanks

Enrique

Re: enable 2fa for UAA zone

Enrique Cano
 

Hi Dan

Is the expectation then that we would integrate with the external IdP via SAML?

Thanks

Enrique
Routing Release 0.198. 0

Keshav Sharma
 

Hello cf-eng, 
Routing Release 0.198.0 has been cut! 

Release Highlights

  • When application developers embed content and also enable sticky sessions, they want cookies to travel through embedded content. The gorouter now sets vcap_id SameSite value based on JSESSIONID to prevent a sticky session error details

CF-Bosh Networking
Re: On SelfServiceLinksEnabled #uaa

JohnG
 

Thanks again Dan for your feedback. We will certainly try that option. Good day.

best regards
-CG
Re: enable 2fa for UAA zone

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?


 
Re: On SelfServiceLinksEnabled #uaa

Dan Beneke
 

Hi CG - 

It looks as if you've taken the right step to disable the create account and password reset links.  We'd expect selfServiceLinksEnabled to have the documented effect (determines if users are allowed to sign up or reset their passwords via the UI) and aren't aware of open issues with its function.  Keep in mind that this value isn't global as it can be set for each individual identity zone.  If you think you've found a bug/issue, I'd encourage you to open a github issue supplying content that will allow the team to recreate the situation.

As for suppressing just one of the two self service links, that feature isn't offered.  Currently, enablement or disablement occurs jointly.  If it's of any value, you do have the option to set the destination http link for the 'create an acct' experience using config.links.selfService.signup .  I've seen implementations wherein this link takes users to a joint self service page with the information they need to either create an account or reset their password.

Regards,
Dan Beneke 

On Mon, Feb 3, 2020 at 9:07 AM JohnG via Lists.Cloudfoundry.Org <ci_98yr=yahoo.com@...> wrote:
in the uaa.yml, when I set selfServiceLinksEnabled to false 
under 
login:
  selfServiceLinksEnabled: false

they (create an acc and password reset link) still appear. Any reliable way to disable them?

Further, is there a way to just suppress "create an acc" with selfServiceLinksEnabled: false ?
and still have self service password reset enabled?

Thanks in anticipation

best regards
-CG

Re: New CLA tool for Cloud Foundry

Chris Clark
 

Hi all,

I’ve got a few updates to the EasyCLA migration, now a few months behind us:

 We’ve removed the prompt to click on “CFF Migration” for previously whitelisted contributors. We’ll be deprecating this shortly, as it was intended as a temporary bridge to minimize disruption to contributors and avoid having covered committers and companies re-sign a CLA. At this point we assume the vast majority of active committers has already signed up with EasyCLA (anyone who has a commit since October has, and that's over 500 committers). Going forward, we’ll ask everyone else to sign a new CLA, which should only take a minute or two. 

Previously, the cloudfoundry and cloudfoundry-incubator GitHub orgs had been whitelisted. This should not have been the case. While the majority of these orgs’ members are covered by an existing CCLA or ICLA, membership in those orgs alone should not exempt committers from being covered by a CLA. Going forward, these orgs will not be whitelisted… so, if you’ve authorized EasyCLA with "CFF Migration" and your whitelisting was based on membership in one of these orgs alone, you may need to re-authorize EasyCLA and select your employer's CCLA, or sign an ICLA. Either way, this should just take a couple minutes.

Bots: If you have an issue with a CI (or any other) bot that makes commits (and therefore will trigger the CLA check), please open a ticket with LF IT (the EasyCLA app will prompt this in the GitHubPR), and they should be able to take care of this for you.

Please reach out to me, or LF IT, if you have any questions, issues, or feedback. Thank you again for your patience with all this!  

 

 
Re: enable 2fa for UAA zone

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.
Re: enable 2fa for UAA zone

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.
Re: enable 2fa for UAA zone

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

On Sat, Feb 1, 2020 at 7:23 PM JohnG via Lists.Cloudfoundry.Org <ci_98yr=yahoo.com@...> wrote:
>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!

On SelfServiceLinksEnabled #uaa

JohnG
 

in the uaa.yml, when I set selfServiceLinksEnabled to false 
under 
login:
  selfServiceLinksEnabled: false

they (create an acc and password reset link) still appear. Any reliable way to disable them?

Further, is there a way to just suppress "create an acc" with selfServiceLinksEnabled: false ?
and still have self service password reset enabled?

Thanks in anticipation

best regards
-CG
Re: New lead for Community (CAB) meetings

Swarna Podila
 

Hi Everyone,
Bringing this to the top of your inboxes, y'all.  

Please send in your nominations by Wednesday, February 5th.

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.


On Thu, Jan 23, 2020 at 7:54 AM Swarna Podila <spodila@...> wrote:
Dear CF Community,
Max (popularly known as "Dr. Max", cc'd here) has been running Cloud Foundry Community Advisory Board (CAB) meetings for the past 4-ish years now.  As he mentioned during the recent calls, 2020 is a great opportunity for any of you in the community to nominate yourself (or someone you know is interested) to take the baton from Max.  Max will continue being an active member of our community; we just think that other members may want to take an opportunity to step up and make their mark in our community.  

The responsibilities will be to host 
  • the monthly CAB calls by sourcing interesting topics/demos for the meetings
  • in-person CAB meetings at Cloud Foundry Summits (we, from the Foundation, can help you with that)
If you are unsure of the responsibilities or if you would like to talk to Max directly, please feel free to reach out to him.

Please send us your nominations no later than February 5th. 

-- Swarna Podila (she/her)
Senior
 Director
, Community
 | Cloud Foundry Foundation

You can read more about pronouns here, or please ask if you'd like to find out more.
Re: enable 2fa for UAA zone

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!
Re: enable 2fa for UAA zone

Dr Nic Williams <drnicwilliams@...>
 

I think the UAA team deprecated or removed 2FA/MFA features.

Nic
--
Dr Nic Williams
Stark & Wayne LLC
+61 437 276 076
twitter @drnic
561 - 580 of 9432