[jira] [Commented] (OAK-4845) Regression: DefaultSyncContext does not sync membership to a local group

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

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

Alexander Klimetschek commented on OAK-4845:
--------------------------------------------

Some folks using our product & IDP ran into this issue again. The problem can really be a *chicken and egg scenario*:

# the Oak-based system & application is setup by vendor A for customer X, before customer X onboards
# an organization within the external identity provider system is given to customer X, within which they can add their users and groups as they choose
# this happens after the provisioning of 1.
# there is a standard local role group in the Oak-based system, e.g. "foobar-users" that aggregates the permission to use a part of the application called "foobar"
# customer X wants to map an external group to that role, i.e. control in their IDP what users would should be part of foobar-uses; this might use a standardized name for the external group, say "foobar-external"
# thus vendor A wants to setup that mapping of "foobar-external" being a member of "foobar-users" _before_ the customer X onboards

Unfortunately, vendor A cannot run an IDP sync yet, as the external group "foobar-users" doesn't really exist yet. It is worth noting that even running the sync in the first place can be difficult before the customer was fully onboarded and has done extra steps. Thus the only way is to create it locally - but then the DefaultSyncHandler will fail to update it as it's not an external group.

Here is another *simple possible solution*:

In the DefaultSyncHandler, sync an external group to an existing local group ONLY if that group is completely empty (= no members), and turn it into an external group on the first sync. That step would be irreversible, i.e. the group would then stay external.

This should allow setup of such a group locally just as vehicle to define the roles an external group should have (i.e. member of what other groups it should be). At that point there are no members at all. Once the group is turned external, all the usual protection applies, including the "remove member" issue discussed above.

> 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.4.7, 1.5.3
>            Reporter: Alexander Klimetschek
>            Assignee: Dominique Jäggi
>            Priority: Critical
>             Fix For: 1.6.0
>
>         Attachments: missing-commits-in-tests.patch, OAK-4845.patch, OAK-4845-test-lostmembership.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.4.14#64029)