cf-cli allows create users with same ID but different origin.

[keymon]

Command

cf create-user test test1
cf create-user test --origin ldap

What occurred

It is possible to multiple users with the same name if the origin is different (e.g. one local user using UAA and one LDAP).

But the user operations in the cf-cli and in Cloud Controller does not handle properly multiple users with same login. For instance: assign roles, login, listing operations by users, listing roles.

When using the same origin, the cf cli does not create the user, reporting user test already exists and exiting successfully.

$ cf create-user test test1
Creating user test...
OK
$ cf create-user test test1
Creating user test...
user test already exists
OK

But with different origins, cf-cli does not check if the user already exists, allowing to create two users with same names, with two users in the UAA server with different origin.

Problems

This causes confusion and operational issues.

• The users have internally in CC different GUID, so they are different users:

  • When login in, UAA would match any of the UAA methos
  • But once login, the user is different, as it has a different GUID. The user does not know which "user instance" he is login in
  • Different set of permissions and roles.

• when assigning roles to users set-org-role unset-org-role set-space-role unset-space-role:

  • cf-clie does not allow specify which user representation to add to the group.
  • the CC [endpoints of CC do not allow specify which user must be added when adding by username [https://apidocs.cloudfoundry.org/272/organizations/associate_manager_with_the_organization_by_username.html]. Which one is added?
  • Even if it allowed, the operators would have to add the users twice to keep consistency...

• Audit logs do not say which user did the operation

• Listing orgs and space users do not display which user is in the space (LDAP or UAA)

What you expected to occur

I have the feeling that both CC and cf-cli are not ready to support users with multiple UAA representations (multiple auth methods).

We have several options:

• Until CC+cf-cli fully support multiple UAA users with the same name, we should not allow to create more than one user with same name. The operators can use a naming convention for supporting multiple auth: username@uaa vs username
• CC should decouple the users GUID in UAA from an internal CC GUID, allowing one CC user to map to multiple UAA user instances. That would support the model of one user, multiple auth methods.
• Keep having each user differently. We should be able to pass --origin to every single operation in the cf-cli. IMO I think this is the worse design, as every single operation would have to support more logic, it is error prone and difficult to understand and operate.

CLI Version

cf version 6.29.0+ff886fa.2017-07-24

CC API Endpoint Version

api version:    2.98.0

[cf-gitbot]

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

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

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

[dkoper]

Hi @keymon

Are you pointing out a theoretical issue (and limitations) of creating multiple same-named users with different origin, or are you experiencing this issue in a live environment? UAA supports same-username-different origin, and CC had recently added it too (actually, not sure if that's gone out in a CF release yet - it should be in the next one).

So for the CLI, I expect at some point we'd also enhance all commands that take a username to also take an origin (your second option), and/or, if in general there are no more than one origin used per org, the user experience may be better if it defaulted to the origin of the Space/Org Manager (for the case where it's not the admin doing the role management).

If we want to grant roles to an org, one one of the user is assigned (usually the last one): cf set-space-role test test-org test-dev SpaceDeveloper

This was fixed in cf CLI 6.33.0 and CAPI and now returns an error.

Regards, Dies Koper CF CLI PM

[keymon]

My issue description was not as good as it should, and I updated it. Check the "Problems" and "What you expected to occur", but I would explain them in this comment.

I also think this is a design issue that should be discussed with the CAPI team: How represent users with multiple authentication methods (aka, multiple UAA users with same id).

Are you pointing out a theoretical issue (and limitations) of creating multiple same-named users with different origin, or are you experiencing this issue in a live environment?

We currently suffered in production. Some UAA managed users used for deployments were also accidentally created with --origin ldap, which caused some weird issues in our side. We had to manually remove the "ldap" version of the users, and fix all the role assigment.

UAA supports same-username-different origin, and CC had recently added it too (actually, not sure if that's gone out in a CF release yet - it should be in the next one).

Can you elaborate further how this would work, and what would be the transition process?

I couldn't find too much info about that, but cecking the current versions of the CC and cf-cli, and our deployment (2.98.0):

• CC maps users in UAA 1 to 1. So each user in UAA with different "origin" is a different user.
• cf login delegates to UAA for auth. The user might login inconsistently with any of the users.
• Each user is different for all the features in CC and cf-cli
  • for role assignation, different set of permissions and roles.
  • for audit: Which user did what?

As an operator and user, I find all of this quite confusing. I struggle to find the use case of having "different CAPI users" based on the auth method in UAA (e.g local DB vs. LDAP). But I do understand the use case of having the same CAPI user with multiple auth methods: (e.g. local DB, Oauth, LDAP...

So for the CLI, I expect at some point we'd also enhance all commands that take a username to also take an origin (your second option), and/or, if in general there are no more than one origin used per org, the user experience may be better if it defaulted to the origin of the Space/Org Manager (for the case where it's not the admin doing the role management).

TBH That approach also feels confusing and error prone:

• As a CF operator, it is an overhead to know which "representation" of the user is being managed in each case.
• It requires lots of logic and checks to add to the cf-cli.

What do I suggest to do?

I think the current user experience around all this is not too consistent and well defined. Even if the latest versions CAPI and cf-cli would support this use case, the CF deployments in the community do not.

One solution can be that the cf-cli should prevents create a user if it already exists with the same name name. Or it is prevented in the CC. This check could be optionally disabled.

[dkoper]

@sreetummidi Our cf auth and cf login command (non-sso case) calls the following API passing in the user specified username & password. https://docs.cloudfoundry.org/api/uaa/version/4.7.1/index.html#password-grant

In the case @keymon mentioned - two same-named users with different origin, e.g. ldap and uaa, what does this API return? Would it return an error (can't disambiguate the intended user)? Or a token for... which of the two users?

[keymon]

@dkoper in the test I did, it returns the token for the method that authenticates with the given password. I didn't test which one returns if both passwords are the same.

[abbyachau]

cc @tnwang for visibility

[tnwang]

cc @sreetummidi

We would like to have CF CLI enable selectable identity provider based upon an upcoming feature of UAA around login hint, which will allow control over which of internal user store, LDAP, and OIDC password grant (upcoming new feature) is used.

Users would then be able to specify the origin:

cf login --origin uaa
cf login --origin ldap
cf login --origin oidc-provider1
cf login --origin oidc-provider2

This would be transparent for CC as CC sees a standard UAA user ID (same username flows would meet the same challenges as they do today with CC - this use case introduces nothing new to the current state).

[torsten-sap]

@keymon

You brought up a lot of valid points. As you noticed, the UAA is capable to handle multiple users with the same username but different origin values (e.g. "uaa" and "ldap"). This is an UAA feature that is well documented: https://docs.cloudfoundry.org/uaa/uaa-concepts.html#users

"An individual user can be uniquely identified by the combination of the username and the origin values."

But as you noticed the CLI is not yet completely capable to support this feature in all flavors.

Recently we had some discussions with the CLI team and the UAA team on how to move forward with this. In this context we also reviewed this issue to verify that our solution proposal also matches your needs. Thus, I will summarize what we discussed regarding the problems that you mentioned. Afterwards, I will outline the solution proposal.

Comments on the Problems

The users have internally in CC different GUID, so they are different users

This was already tackled last year with the configuration possibility of a defaultIdentityProvider. This value can be set to any origin that is registered in the UAA. It has the effect that a user is by default only authenticated with that origin. If you configure it to "uaa" an user will not be able to login with origin "ldap" using "cf login" or "cf auth". However, a user might explicitly state that he wants to login with origin "ldap" using the option "--origin" with CLI command "cf auth" ("cf login" does not yet support "--origin").

The advantage of this feature is that the user always knows with which origin he is logged in. It is either the default one or the one that the user explicitly specified.

when assigning roles to users set-org-role unset-org-role set-space-role unset-space-role

Totally true. We are striving to make this assignment explicit, see the solution proposal.

Audit logs do not say which user did the operation

This is currently tackled by the UAA team. Related stories are these:

• https://www.pivotaltracker.com/story/show/165399567
• https://www.pivotaltracker.com/story/show/165399693

Further, the UAA team will clarify the audit log situation for role assignment.

Listing orgs and space users do not display which user is in the space (LDAP or UAA)

Totally true. We are striving to enhance the output of these commands, see the solution proposal.

Solution Proposal

After the discussion of all options that you mentioned (and that we came up with) we strongly favor the third one, meaning "Keep having each user differently." as you name it. The main reasons are:

• consistent with the currently documented and well-known UAA behavior
• consistent with regards to user experience
• CLI commands "cf auth" and "cf create-users" already support the option "--origin" and thus multiple origins for the very same username
• smoothest way forward
• fewest customer implications

Note that in contrast to your assumption not all CLI commands are affected but only the ones that target the user in some way.

We created the following feature requests that illustrate the complete picture of the envisioned CLI changes.

• cf login: https://github.com/cloudfoundry/cli/issues/1599
• cf set-space-role: https://github.com/cloudfoundry/cli/issues/1601
• cf-set-org-role: https://github.com/cloudfoundry/cli/issues/1602
• cf delete-user: https://github.com/cloudfoundry/cli/issues/1603
• cf org-users: https://github.com/cloudfoundry/cli/issues/1621
• cf space-users: https://github.com/cloudfoundry/cli/issues/1622

[bwasmith]

I believe this work is completed. There were collaborations between SAP and the UAA team, and this behavior is exposed via the v7 CLI. All of the above feature requests were completed.

$ cf -v                                                                                                                                                                                                                                                     
cf version 7.0.0-beta.29+d08ccdb72.2020-01-27                                                                                                                                                                                                                                

$ cf create-user -h                                                                                                                                                                                                                                         
NAME:                                                                                                                                                                                                                                                                        
   create-user - Create a new user                                                                                                                                                                                                                                           

USAGE:                                                                                                                                                                                                                                                                       
   cf create-user USERNAME PASSWORD                                                                                                                                                                                                                                          
   cf create-user USERNAME [--origin ORIGIN]                                                                                                                                                                                                                                 
   cf create-user USERNAME --password-prompt                                                                                                                                                                                                                                 

...                                                                                                                                                                                                                                                                                                                                                                                                                       

Thank you for everybody's contributions!