fix: external group memberships should have correct origin

[mikeroda]

External group memberships determined from processing an OIDC or SAML login should be stored with the origin of the identity provider and not the default uaa origin.

[strehle]

please check if my rebase is Ok for you.

Sonar is green: https://sonarcloud.io/summary/new_code?id=cloudfoundry-identity-parent&pullRequest=3033

The issue is known but I was not sure in the past, wheather this is a bug or feature , so from our side (SAP) we can agree to this change but from @hsinn0 @peterhaochen47 broadcom side you should check as well

[mikeroda]

Yes the rebase looks fine to me

[hsinn0]

The issue is known but I was not sure in the past, wheather this is a bug or feature , so from our side (SAP) we can agree to this change but from @hsinn0 @peterhaochen47 broadcom side you should check as well

Thanks, we will take a look at this.

[hsinn0]

We will try to find out whether the existing implementation was intentional or an oversight, and also if there is anything out there that depends on the current behavior.
Meanwhile, a question to @mikeroda. Are you trying to resolve an actual field issue with this change, or did you just find the problem by examining the code?

[mikeroda]

@hsinn0, It is causing an actual issue for me.

[peterhaochen47]

Here is my guess/understanding after a quick read of the existing code:

It looks likeScimUserBootstrap is for processing any users creation/update/delete operations as defined in server config (uaa.yml), which I think only defines UAA internal users, whose origin can only be uaa.

The external IDP users (origin != uaa) are not defined in uaa.yml. They are created as a result of external IDP logins, and their group membership are defined by various relevant settings (e.g. external group mapping), rather than the scim users/groups sections of uaa.yml. At least I think that's the intention, and the reason why when ScimUserBootstrap is processing users, it's always assuming UAA internal users (origin=uaa).

What is the actual issue you are seeing? What is your use case?

[mikeroda]

In addition to processing users in the server config, it also receives events like ExternalGroupAuthorizationEvent, used to process external groups during external logins. Anyway, my commit still works for users processed from the server config.
To answer your question, I have some custom code that does additional processing for external group memberships and I rely on the origin being set correctly.

[peterhaochen47]

In addition to processing users in the server config, it also receives events like ExternalGroupAuthorizationEvent, used to process external groups during external logins. Anyway, my commit still works for users processed from the server config. To answer your question, I have some custom code that does additional processing for external group memberships and I rely on the origin being set correctly.

I see. Yeah I don't see any issues with this PR then.

[hsinn0]

Approving and merged to develop.