Alexander Klimetschek commented on OAK-4845:

Here is a unit test for DefaultSyncContextTest replicating the situation. I 
deliberately verify only the user membership and not checking for 
rep:lastSynced or rep:externalId being set, to test only the actual use case 
that otherwise wouldn't be supported.

     * @see <a 
    public void testMembershipForExistingLocalGroup() throws Exception {

        ExternalUser externalUser = idp.getUser(USER_ID);
        ExternalIdentityRef groupRef = 

        // create the group locally (has no rep:externalId)
        Group gr = userManager.createGroup(groupRef.getId());

        SyncResult result = syncCtx.sync(externalUser);
        assertSame(SyncResult.Status.ADD, result.getStatus());

        User user = userManager.getAuthorizable(externalUser.getId(), 

        // verify membership gets added
        Iterator<Group> declared = user.declaredMemberOf();

> 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
>            Priority: Critical
> 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

Reply via email to