Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect documentation of /Groups/{groupId}/members (origin) #2190

Open
stephanme opened this issue Feb 2, 2023 · 1 comment
Open

Incorrect documentation of /Groups/{groupId}/members (origin) #2190

stephanme opened this issue Feb 2, 2023 · 1 comment

Comments

@stephanme
Copy link

SECURITY NOTICE: If you have found a security problem in the UAA, please do not file a public github issue. Instead, please send an email to [email protected]

Thanks for taking the time to file an issue. You'll minimize back and forth and help us help you more effectively by answering all of the following questions as specifically and completely as you can.

What version of UAA are you running?

Version 76.5.0
https://docs.cloudfoundry.org/api/uaa/version/76.5.0/index.html#add-member

How are you deploying the UAA?

We are using the BOSH release: https://github.com/cloudfoundry/uaa-release/releases/tag/v76.5.0

What did you do?

We add users managed by an identity provider (origin=sap.ids in our case) to a group cloud_controller.v2_api_rate_limit_exempt.
E.g. POST /Groups/<groupId>/members with body {"origin":"sap.ids","type":"USER","value":"<user-guid>"}

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

When the user works with cf cli, the user shall have the the scope cloud_controller.v2_api_rate_limit_exempt so that it gets exempted from CF API v2 rate limiting. This is a CAPI specific functionality. The UAA client cf used by cf cli is properly configured to support the scope cloud_controller.v2_api_rate_limit_exempt. See also cloudfoundry/docs-running-cf#109 (doc about CF API v2 rate limiting, not yet merged unfortunately).

What did you see instead?

The membership of an added user to the group cloud_controller.v2_api_rate_limit_exempt disappeared silently when the user authenticated (e.g. using cf login).

There were no related UAA logs (expected to see GroupModifiedEvent logs) -> #2189

After a discussion with UAA committers it turned out that the origin parameter of the POST /Groups/<groupId>/members is not the origin of the user but the origin of the membership. If set to sap.ids UAA tries to get group membership from the identity provider configured for sap.ids. Since it doesn't know any group cloud_controller.v2_api_rate_limit_exempt, the membership is removed from UAA.
If we set the origin parameter to uaa it works as expected and the membership remains when the user logs in.

However, https://docs.cloudfoundry.org/api/uaa/version/76.5.0/index.html#check-membership specifies the origin parameter as:

The originating IDP of the entity, or "uaa" for groups and internal users

With "entity" the user or group is meant that is added as member to a group (at least this is how I read the documentation). SInce we added an sap.ids user, we specified sap.ids as origin in the add-member call and bad things happened.

The documentation should be corrected.

@cf-gitbot
Copy link

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

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

2 participants