[
https://issues.apache.org/jira/browse/OAK-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15556027#comment-15556027
]
Alexander Klimetschek edited comment on OAK-4397 at 10/7/16 7:25 PM:
---------------------------------------------------------------------
Turns out, OAK-4845 is not a regression, as it would only get more complex down
the line.
Possible workarounds for existing applications relying on the previous behavior
that allowed adding memberships to local groups (and these were really only
intended as "placeholder" for the external groups):
* right before a batch sync is run, remove the local group and get it
automatically recreated using the right {{rep:externalId}} (if temporarily
loosing the group has no bad consequences; note that ACs would not be affected)
* temporarily disable the {{rep:externalId}} protection
({{protectExternalId=false}}, see
[docs|http://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration_of_the_ExternalPrincipalConfiguration]),
set the correct {{rep:externalId}} values on existing groups, enable
protection again
was (Author: alexander.klimetschek):
Turns out, OAK-4845 is not a regression, as it would only get more complex down
the line.
Removing membership from local groups could create problems, if both a local
and external group accidentally have the same name. A completely separate,
locally established group membership should not be inadvertently be removed by
a sync. Furthermore, supporting adding memberships to local groups on one hand,
but not removing, creates an inconsistency and would not provide the guarantee
expected from the sync, that the group memberships in the JCR represent the
ones from the external IDP.
Possible workarounds for existing applications relying on the previous behavior
that allowed adding memberships, and had local groups that really are only used
as placeholder for the external groups:
* right before a batch sync is run, remove the local group and get it
automatically recreated using the right {{rep:externalId}} (if temporarily
loosing the group has no bad consequences; note that ACs would not be affected)
* temporarily disable the {{rep:externalId}} protection
({{protectExternalId=false}}, see
[docs|http://jackrabbit.apache.org/oak/docs/security/authentication/external/defaultusersync.html#Configuration_of_the_ExternalPrincipalConfiguration]),
set the correct {{rep:externalId}} values on existing groups, enable
protection again
> 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, 1.4.7
>
>
> 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)
