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

Shadow Users are not getting updated after user logs out and login again #2917

Closed
Rohit04061992 opened this issue Jun 5, 2024 · 4 comments · Fixed by #2922 or #2923
Closed

Shadow Users are not getting updated after user logs out and login again #2917

Rohit04061992 opened this issue Jun 5, 2024 · 4 comments · Fixed by #2922 or #2923
Labels

Comments

@Rohit04061992
Copy link

Rohit04061992 commented Jun 5, 2024

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 security@cloudfoundry.org

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?

What output do you see from curl <YOUR_UAA>/info -H'Accept: application/json'?

How are you deploying the UAA?

77.10.0

Problem Statement

Today when 2 uaa are used federating with each other the shadow users that gets created is not getting updated with new set of permissions coming from access_token from the other uaa counterpart.

So what we see is shadow user , gets updated with new permissions when user authenticates but it does not remove the permissions that has been removed .

My user journey is like this

  1. User logins to the uaa (which is integerated with any Auth0 Powered IDP)
  2. Application gets the access_token , id_token and refresh_token
  3. User has been removed with some previleges
  4. Now user logs out and login again
  5. He is not getting the access token reflecting the role assignments
    Typically roles that are removed are not removed but roles that are added can be seen
@cf-gitbot
Copy link

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

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

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

@strehle
Copy link
Member

strehle commented Jun 6, 2024

I assume you mean you set in yml:
attributeMappings:
external_groups:
roles

And the roles from your IdP has be changed.

Will verify and if yes, then we have bug, yes.

@Tallicia FYI

@Rohit04061992
Copy link
Author

So here when certain groups are assigned to the user in idp , they get reflected in the shadow user but when certain memberships are deleted then even though the access token coming from the idp has updatd set of groups(like not having the ones that are being removed ) is not deleting the groups (that are no more valid ) in the shadow user

@strehle
Copy link
Member

strehle commented Jun 6, 2024

I can confirm this issue.

@peterhaochen47 FYI

I configured in uaa.yml

`

 oauth:
    providers:
      sandbox.proxy:
        type: oidc1.0
        passwordGrantEnabled: true
        discoveryUrl: https://myidp.cloud.sap/.well-known/openid-configuration
        issuer: https://myidp.cloud.sap
        scopes:
          - openid
          - email
          - profile
          - groups
        linkText: Login with SAP Sandbox Proxy
        relyingPartyId: cabcf123-c11f-1111-aaaa-abcdabcdabcd
        groupMappingMode: AS_SCOPES
        authMethod: none
        attributeMappings:
          user_name: email
          external_groups:
            groups
        showLinkText: true

`

Then on my IdP I set certain groups for the user, e.g. group1, group2

And in oauth-client supported group1, group2, group3, etc.

With login to UAA (and proxy to IdP) , requested scope"group1 group2" I received a new Shadow user with and scope assignment of ["group1", "group2"]. After logout and login in UAA (and ext. IdP) and removal of group2 in IdP I started login again.

Result still is: ["group1", "group2"]
-> Reason is, that with intial login this method is executed
https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/scim/bootstrap/ScimUserBootstrap.java#L251-L252

If I perform steps like :
Add group3 in IdP configuration and retrieve UAA token with scope group3, remove this , lgout and login, then the group3 is removed from scope.

-> Reason is, that for existing shadow user, this method is executed

https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/scim/bootstrap/ScimUserBootstrap.java#L255

If a GroupMemberShip entry is done with the wrong origin, then this assignment is not removed and stays.
If the GroupMemberShip is with the correct origin, then this method here removes groups correctly.
https://github.com/cloudfoundry/uaa/blob/develop/server/src/main/java/org/cloudfoundry/identity/uaa/scim/bootstrap/ScimUserBootstrap.java#L232

@strehle strehle added the bug label Jun 6, 2024
strehle added a commit that referenced this issue Jun 7, 2024
Test shows:
SAML OK
OIDC we have an issue
@strehle strehle linked a pull request Jun 7, 2024 that will close this issue
strehle added a commit that referenced this issue Jun 7, 2024
Perform shadow user creation (NewUserAuthenticatedEvent)
without authorities creation, but rely on event
ExternalGroupAuthorizationEvent later.

Includes: IT for testing a fix of issue #2917
@strehle strehle linked a pull request Jun 7, 2024 that will close this issue
strehle added a commit that referenced this issue Jun 11, 2024
* IT for testing a fix of issue #2917

Test shows:
SAML OK
OIDC we have an issue

* Fix issue #2917

Perform shadow user creation (NewUserAuthenticatedEvent)
without authorities creation, but rely on event
ExternalGroupAuthorizationEvent later.

Includes: IT for testing a fix of issue #2917
strehle added a commit that referenced this issue Jun 11, 2024
Test shows:
SAML OK
OIDC we have an issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging a pull request may close this issue.

3 participants