[
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)
