jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-4845) Regression: DefaultSyncContext does not sync membership to a local group
Date Mon, 03 Oct 2016 20:36:20 GMT

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

Alexander Klimetschek commented on OAK-4845:

To add: the main reasoning to change this to wontfix was that 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
set the correct {{rep:externalId}} values on existing groups, enable protection again

> Regression: DefaultSyncContext does not sync membership to a local group
> ------------------------------------------------------------------------
>                 Key: OAK-4845
>                 URL: https://issues.apache.org/jira/browse/OAK-4845
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: auth-external
>    Affects Versions: 1.5.3, 1.4.7
>            Reporter: Alexander Klimetschek
>            Assignee: Dominique Jäggi
>            Priority: Critical
>             Fix For: 1.6
>         Attachments: OAK-4845-test-lostmembership.patch, OAK-4845.patch, missing-commits-in-tests.patch
> OAK-4397 introduced a regression: it does not allow syncing to a locally existing group
anymore (that does not belong to another IDP).
> Updating to 1.4.7 now gives "Existing authorizable 'X' is not a group from this IDP 'foo'.",
and the group is not synced and most importantly, memberships for external users are not updated
anymore. Looking at the group in JCR, it does not have a {{rep:externalId}} at all, only a
> Code wise, this is because the {{rep:externalId}} is only ever set in {{createGroup()}},
i.e. when the external sync creates that group initially. If the group is already present
locally (but not owned by another IDP!), then it won't use it due to the new {{isSameIDP()}}
check, which will also fail if there is no {{rep:externalId}} property set.
> The use case is that we are defining the group locally as part of our application already
(including ACs etc.) and we want certain external users be added to it, based on some some
of their settings on the external IDP side. FWIW, we don't care for the syncing of properties
for the group itself, just for the memberships.

This message was sent by Atlassian JIRA

View raw message