Problem when adding users with same name different letter case, from different origins
bjalonmontanes opened this issue · 7 comments
Describe the bug
We are trying to add users from uaa and saml using a task that runs cf-mgmt update-space-users command. The thing is that, on the space config files the users within the users array are listed in all lower case user.name@example.com. The users into the saml array have a capital first letter User.Name@example.com
It appears to be 50-50 if it will pick the user with the lower or upper case to then add to the spaces.
If it picks the user User.Name@example.com (from saml) then the user is added in from uaa and saml . If it picks the one with the lower case user.name@example.com then this user appears to always appear in the task everytime it runs and it doesn’t seem to actually put them in the space. There is not output to say it has failed but it repeats the same user each time picking the lower case name.
If the user list is short, it will fail 100%.
To Reproduce
Steps to reproduce the behavior:
Create a user in uaa, name.lastname@example.com and then put that in the users array and then Name.Lastname@example.com in the saml_users array.
Run cf-mgmt update-space-users command, and you'll see that it only adds name.lastname@example.com , although it appears twice in the commands output. E.g
$ cf-mgmt update-space-users --system-domain=run-20.slot-59.pez.vmware.com --user-id=cf-mgmt --client-secret=cf-mgmt-secret
2021/07/21 15:59:22 W0721 15:59:22.020792 49718 yaml_config.go:546] Ldap bind password should be removed from ldap.yml as this will be deprecated in a future release. Use --ldap-password flag instead.
2021/07/21 15:59:38 I0721 15:59:38.750581 49718 users.go:94] adding name.lastname@example.com to role developer for org/space test/test-space
2021/07/21 15:59:39 I0721 15:59:39.951816 49718 users.go:94] adding name.lastname@example.com to role developer for org/space test/test-space
and all the next executions it shows the user is added. E.g.
cf-mgmt update-space-users --system-domain=run-20.slot-59.pez.vmware.com --user-id=cf-mgmt --client-secret=cf-mgmt-secret
2021/07/21 16:15:59 W0721 16:15:59.497327 51571 yaml_config.go:546] Ldap bind password should be removed from ldap.yml as this will be deprecated in a future release. Use --ldap-password flag instead.
2021/07/21 16:16:16 I0721 16:16:16.772073 51571 users.go:94] adding name.lastname@example.com to role developer for org/space test/test-space
So it seems that it checks if the user already exists already in uaa, and if it does, some how, it picks the uaa user instead of the saml user.
This is the snippet of spaceConfig.yml
org: test
space: test-space
space-developer:
ldap_users: []
users:
- admin
- name.lastname@example.com
saml_users:
- Name.Lastname@example.com
Expected behavior
Users from saml should be added to the space
Additional context
If users don't exist in uaa and you run the command with only saml_users filled, then users are added to the space correctly.
But if then you add users in uaa and run the command with the users array, it will complain saying that the user "doesn't exist in origin uaa, so must add internal user first" when the user indeed exists.
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.
The labels on this github issue will be updated when the story is started.
Hey there @bjalonmontanes I can see from the code that users from LDAP / SAML are assumed to be in UAA, and assumed that even if SAML users have Upper case characters, they are always converted to lower.
That's the current behaviour which matches your output above. Therefore your LDAP / SAML / UAA users regardless of Upper/Lower are assumed to be the same, i.e.
A@test.com == a@test.com == a@TEST.com etc...
@mstergianis , this seems like a product choice was made, and the assumption the code makes is the opposite of what this issue is requesting. WDYT?
this seems like a product choice was made
Can't speak to the original product choice, but this is consistent with what I think. While the standard allows for case sensitive email addresses, it is not something you see in practice.
From RFC 5321:
While the above definition for Local-part is relatively permissive,
for maximum interoperability, a host that expects to receive mail
SHOULD avoid defining mailboxes where the Local-part requires (or
uses) the Quoted-string form or where the Local-part is case-
sensitive.
In addition, cf-mgmt will try to create a uaa user based on the saml user definition.
So, the intended use case here is; if the user's source of truth is SAML, they only appear in the saml_users array, not both.
Though maybe I'm misunderstanding the problem. Is the intent that each user has two sign-ins to the cf instance?
e.g. I as a user could do
cf login -a my-cf.example.com -u my.email@example.com -p my-super-secret-passwordAlternately, intending to be a slightly different user
cf login -a my-cf.example.com --ssoThings I have tried:
Test Case 1
Added a user to saml_users field that does not exist in UAA.
I got the following error from cf-mgmt update-space-users:
Unable to create user Neil3@vmware.com
This was possibly just an error for the env I am using. As mentioned above, the behaviour is to create a user in UAA.
Test Case 2
Added a user to saml_users field that does exist in UAA
WHERE saml_users field was Neil3@vmware.com and users field was neil3@vmware.com
I got the following from cf-mgmt update-space-users:
2021/07/21 15:56:20 I0721 15:56:20.491951 89901 users.go:94] adding neil3@vmware.com to role developer for org/space test/test-space
2021/07/21 15:56:20 I0721 15:56:20.836599 89901 users.go:94] adding neil3@vmware.com to role developer for org/space test/test-space
user added to space under the name neil3@vmware.com. Cannot login via SAML.
Test Case 3
Added a user to saml_users field that does exist in UAA
WHERE saml_users field was Neil4@vmware.com
Ran: cf create-user Neil4@vmware.com <password>
Ran: cf-mgmt update-space-users:
2021/07/21 16:16:20 I0721 16:16:20.856229 93538 users.go:94] adding Neil4@vmware.com to role developer for org/space test/test-space
User was assumed to exist in UAA for SAML also. It didn't create another user for SAML in UAA => could not login via SAML with this user.
Though maybe I'm misunderstanding the problem. Is the intent that each user has two sign-ins to the cf instance?
Yes @mstergianis , that is the use case, users can login with both uaa and saml users.
Thans!
Interesting @bjalonmontanes. I'd love to know more of why each user has two cf accounts.
As it stands right now though, I don't think we'll be changing this behaviour. Treating email addresses as case sensitive is not something I want to unpack 😂.
Sorry, that this doesn't fit your use case. Have you considered omitting the email address for the native UAA acocunts? I don't believe UAA has a constraint that user accounts be email
hey @bjalonmontanes , given the reply to this thread, I will close this issue out tomorrow. Feel free to re-open / open another if you feel it is not resolved.