[
https://issues.apache.org/jira/browse/OAK-4845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144319#comment-16144319
]
Alexander Klimetschek edited comment on OAK-4845 at 8/28/17 8:49 PM:
---------------------------------------------------------------------
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.
was (Author: alexander.klimetschek):
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)
