[jira] [Comment Edited] (OAK-4397) DefaultSyncContext.syncMembership may sync group of a foreign IDP

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

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