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

Alexander Klimetschek edited comment on OAK-4397 at 9/22/16 10:29 PM:
----------------------------------------------------------------------

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}}.

AFAICS, this is because the {{rep:externalId}} is only ever set in 
{{createGroup()}}, i.e. when the external sync creates that group initially. If 
it's already there (but not owned by another IDP!), then it won't use it.

Note that we don't care for the properties of the group, we just need it to add 
users to it based on some rules on the external identity system side (it's a 
bit more complex system on that side). So maybe the new check should only apply 
to syncProperties for the group, but not for adding users to the group.

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.


was (Author: alexander.klimetschek):
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}}.

AFAICS, this is because the {{rep:externalId}} is only ever set in 
{{createGroup()}}, i.e. when the external sync creates that group initially. If 
it's already there (but not owned by another IDP!), then it can't use it.

Note that we don't care for the properties of the group, we just need it to add 
users to it based on some rules on the external identity system side (it's a 
bit more complex system on that side).

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