[
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
[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
> 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
> {{rep:lastSynced}}.
> 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
(v6.3.4#6332)
