[ 
https://issues.apache.org/jira/browse/OAK-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15514646#comment-15514646
 ] 

Alexander Klimetschek commented on OAK-4397:
--------------------------------------------

This introduced a regression: we have a group X created locally (used for 
setting up ACs in application packages etc.), and our custom external identity 
provider maps to it as an ExternalGroup. However, when running a new 
oak-auth-external version with this change, we get "Existing authorizable 'X' 
is not a group from this IDP 'foo'.", and the group is not synced and most 
importantly, memberships are not updated anymore. Looking at the group in JCR, 
it does not have a {{rep:externalId}} at all, only a {{rep:lastSynced}}.

BTW, I noticed this has been [backported to the 1.4 
branch|https://github.com/apache/jackrabbit-oak/commit/d0251e3efbd6f24e47c06a0d7394816748ef18f8]
 already, the fix version might need an update.

> DefaultSyncContext.syncMembership may sync group of a foreign IDP
> -----------------------------------------------------------------
>
>                 Key: OAK-4397
>                 URL: https://issues.apache.org/jira/browse/OAK-4397
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: auth-external
>            Reporter: angela
>            Assignee: angela
>            Priority: Critical
>              Labels: security
>             Fix For: 1.5.3
>
>
> With the following scenario the {{DefaultSyncContext.syncMembership}} may end 
> up synchronizing (i.e. updating) a group defined by an foreign IDP and even 
> add the user to be synchronized as a new member:
> - configuration with different IDPs
> - foreign IDP synchronizes a given external group 'groupA' => rep:externalID 
> points to foreign-IDP (e.g. rep:externalId = 'groupA;foreignIDP')
> - my-IDP contains a group with the same ID (but obviously with a different 
> rep:externalID) and user that has declared group membership pointing to 
> 'groupA' from my IDP
> if synchronizing my user first the groupA will be created with a 
> rep:externalId = 'groupA;myIDP'.
> however, if the group has been synced before by the foreignIDP the code fails 
> to verify that an existing group 'groupA' really belongs to the same IDP and 
> thus may end up synchronizing the group and updating it's members.
> IMHO that's a critical issue as it violates the IDP boundaries.
> the fix is pretty trivial as it only requires testing for the IDP of the 
> existing group as we do it in other places (even in the same method).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to