scim individual users not mapping correct groups when generating tokens

[thelangley]

What version of UAA are you running?

77.16.0

How are you deploying the UAA?

I am deploying the UAA

• using a bosh release I downloaded from bosh.io
• using cf-deployment v43.6.0

What did you do?

Using ops files, insert sections to create/import specific accounts in LDAP to give specific permissions when used.

Here's an extract from a uaa.yml

scim:
  users:
  - service_account1||service_account1|||cloud_controller.admin,scim.read,scim.write,doppler.firehose,routing.router_groups.read,routing.router_groups.write,routing.routes.read,routing.routes.write|ldap
  - service_account2||service_account2|||cloud_controller.admin_read_only,scim.read,doppler.firehose|ldap

What did you expect to see? What goal are you trying to achieve with the UAA?

On uaa 77.15.0 (the previous release), the correct groups are found when logging in.

[2024-09-30T06:19:13.093476Z] uaa - 11 [https-jsse-nio-8443-exec-4] - [redacted,redacted] .... INFO --- Audit: TokenIssuedEvent ('["openid","routing.router_groups.write","scim.read","cloud_controller.admin","uaa.user","routing.router_groups.read","cloud_controller.read","password.write","cloud_controller.write","doppler.firehose","scim.write"]'): principal=redacted, origin=[client=cf, user=service_account1], identityZoneId=[uaa]

This is the correct behaviour and results in service_account1 being able to see all the orgs/spaces, etc in CF as they have the cloud_controller.admin group assigned. Same goes for service_account2, it has read only access to all orgs/spaces. Logs not shared for service_account2.

What did you see instead?

On uaa 77.16.0, different groups are allocated, not the ones specified in the uaa.yml

[2024-09-30T06:13:13.470329Z] uaa - 12 [https-jsse-nio-8443-exec-4] - [redacted,redacted] .... INFO --- Audit: TokenIssuedEvent ('["openid","uaa.user","cloud_controller.read","password.write","cloud_controller.write"]'): principal=redacted, origin=[client=cf, user=service_account1], identityZoneId=[uaa]

This results in the user not being able to see all the orgs and spaces that we could see in previous versions. I assume because the cloud_controller.admin group is not being used in the token generation.

[strehle]

you create tokens via cf login ?

[thelangley]

yeah it's just doing cf login. those logs are from /var/vcap/sys/logs/uaa/uaa.log

[strehle]

ok, then we can check if https://github.com/cloudfoundry/uaa/pull/3033 is the causing PR for your change.

do a "cf login xxx --origin ldap" or set defaultIdentityProvider: ldap into uaa.yaml

Because I think you problem is the mix of uaa / ldap origin... the groups are now assigned to ldap origin but the token creation is done with origin uaa ( I guess ) and then it would explain the missing groups. / authorities in your token

[thelangley]

Using cf cli v8.7.10, I've done cf login xxx --origin ldap and the uaa logs still appear to say that the groups allocated are incorrect. I also cannot see the orgs/spaces that someone with cloud_controller.admin should be able to see.

[strehle]

are you familiar with uaac ?

If yes, please call: uaac group get cloud_controller.admin