You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Timothée Maret <ti...@gmail.com> on 2013/01/16 10:01:59 UTC
User to tenant mapping
Hi,
I have been using the sling tenant recently and although the tenant path
matcher configuration is
flexbile, the user to tenant resolution mechanism enforces to organize the
users following a fixed
structure where all the users must be under the tenantId root.
As an example:
/home/users/<tenantId>/bob
/us/alice
/fr/charles
This is not flexible enough, especially with enabling tenant support on
legacy system where users
location is already set.
I think there two approaches to improve that
* Based on group
Instead of being applied against the user home path, the regex could be
applied against all the
groups the user is a member of. Each tenant would be assigned to a default
group and the first
tenant.default-group/user.group match would define the user as being part
of the group.
This offers the flexibility to store the user anywhere. However, the
resolution would be undeterministic
in cases where the user has more than one tenant group assigned. Moreover,
this would interleave
group and tenant support which sounds like a limitation in comparison to
the path based approach.
* Based on property set in user home
Each user part of a tenant would have a property "tenantId" set which would
map it to the tenant.
This implies a bit more maintenance but would offer the flexibility to
store users anywhere as well
as a separation between group and tenants.
To me, the property based is clearly the best way to go as it offers most
flexibility in therms of
group and user organization. Moreover, it could be implemented as an
extension of the current design.
Basically, instead of only trying to match against the user home path, the
TenantAdapterFactory could
also look for the userHome + "tenantId" property path. If the property is
present, then the value
could be appended to the user home path and tried to be matched against the
regex.
wdyt ?
Regards,
Timothee.
Re: User to tenant mapping
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 16.01.2013 um 10:45 schrieb Amit.. Gupta.:
>> * Based on property set in user home
>
> Will there be security issue with such approach? As a user would have write access to user node and thus change its tenant. Otherwise this looks fine.
Right. We have to account for this !
At least we have to consider the potential risks: Given that the assets of a tenant are guarded by access control the sheer fact that a user assigns himself as being part of a Tenant should help little, right ?
> A path based approach is advantageous as it allows one to control the acls and thus restrict a tenant's admin to only create users for specific tenant.
I think these are two different pieces of the story: It make sense to organize users pertaining to a given tenant in a separate access controllable location to enable per-tenant user administration.
But I think that assignment of a user to a tenant is something different ?
Should then Tenant "membership" be handled like group membership with the members being managed as a property of the Tenant ?
+ Better control of assigning users to a tenant
- Take care of large multi-value properties (group membership has a similar issue)
- what if a user is referred to by multiple Tenants ?
Regards
Felix
>
> Thanks,
> Amit
> -----Original Message-----
> From: maret.timothee@gmail.com [mailto:maret.timothee@gmail.com] On Behalf Of Timothée Maret
> Sent: 16 January 2013 14:32
> To: dev@sling.apache.org
> Subject: User to tenant mapping
>
> Hi,
>
> I have been using the sling tenant recently and although the tenant path matcher configuration is flexbile, the user to tenant resolution mechanism enforces to organize the users following a fixed structure where all the users must be under the tenantId root.
>
> As an example:
>
> /home/users/<tenantId>/bob
> /us/alice
> /fr/charles
>
> This is not flexible enough, especially with enabling tenant support on legacy system where users location is already set.
>
> I think there two approaches to improve that
>
> * Based on group
>
> Instead of being applied against the user home path, the regex could be applied against all the groups the user is a member of. Each tenant would be assigned to a default group and the first tenant.default-group/user.group match would define the user as being part of the group.
>
> This offers the flexibility to store the user anywhere. However, the resolution would be undeterministic in cases where the user has more than one tenant group assigned. Moreover, this would interleave group and tenant support which sounds like a limitation in comparison to the path based approach.
>
> * Based on property set in user home
>
> Each user part of a tenant would have a property "tenantId" set which would map it to the tenant.
> This implies a bit more maintenance but would offer the flexibility to store users anywhere as well as a separation between group and tenants.
>
> To me, the property based is clearly the best way to go as it offers most flexibility in therms of group and user organization. Moreover, it could be implemented as an extension of the current design.
> Basically, instead of only trying to match against the user home path, the TenantAdapterFactory could also look for the userHome + "tenantId" property path. If the property is present, then the value could be appended to the user home path and tried to be matched against the regex.
>
> wdyt ?
>
> Regards,
>
> Timothee.
Re: User to tenant mapping
Posted by Timothée Maret <ti...@gmail.com>.
Hi,
@felix, yes thanks, I'll give it a try for SLING-2710 and post a patch
there.
2013/1/16 Amit.. Gupta. <am...@adobe.com>
> > * Based on property set in user home
>
> Will there be security issue with such approach? As a user would have
> write access to user node and thus change its tenant. Otherwise this looks
> fine.
>
Maybe an ACL entry under /home/users (deny jcr:write, rep:glob =
"*/sling:tenantId") could avoid that.
> A path based approach is advantageous as it allows one to control the acls
> and thus restrict a tenant's admin to only create users for specific tenant.
>
> Thanks,
> Amit
> -----Original Message-----
> From: maret.timothee@gmail.com [mailto:maret.timothee@gmail.com] On
> Behalf Of Timothée Maret
> Sent: 16 January 2013 14:32
> To: dev@sling.apache.org
> Subject: User to tenant mapping
>
> Hi,
>
> I have been using the sling tenant recently and although the tenant path
> matcher configuration is flexbile, the user to tenant resolution mechanism
> enforces to organize the users following a fixed structure where all the
> users must be under the tenantId root.
>
> As an example:
>
> /home/users/<tenantId>/bob
> /us/alice
> /fr/charles
>
> This is not flexible enough, especially with enabling tenant support on
> legacy system where users location is already set.
>
> I think there two approaches to improve that
>
> * Based on group
>
> Instead of being applied against the user home path, the regex could be
> applied against all the groups the user is a member of. Each tenant would
> be assigned to a default group and the first
> tenant.default-group/user.group match would define the user as being part
> of the group.
>
> This offers the flexibility to store the user anywhere. However, the
> resolution would be undeterministic in cases where the user has more than
> one tenant group assigned. Moreover, this would interleave group and tenant
> support which sounds like a limitation in comparison to the path based
> approach.
>
> * Based on property set in user home
>
> Each user part of a tenant would have a property "tenantId" set which
> would map it to the tenant.
> This implies a bit more maintenance but would offer the flexibility to
> store users anywhere as well as a separation between group and tenants.
>
> To me, the property based is clearly the best way to go as it offers most
> flexibility in therms of group and user organization. Moreover, it could be
> implemented as an extension of the current design.
> Basically, instead of only trying to match against the user home path, the
> TenantAdapterFactory could also look for the userHome + "tenantId" property
> path. If the property is present, then the value could be appended to the
> user home path and tried to be matched against the regex.
>
> wdyt ?
>
> Regards,
>
> Timothee.
>
Regards,
Timothee.
RE: User to tenant mapping
Posted by "Amit.. Gupta." <am...@adobe.com>.
> * Based on property set in user home
Will there be security issue with such approach? As a user would have write access to user node and thus change its tenant. Otherwise this looks fine.
A path based approach is advantageous as it allows one to control the acls and thus restrict a tenant's admin to only create users for specific tenant.
Thanks,
Amit
-----Original Message-----
From: maret.timothee@gmail.com [mailto:maret.timothee@gmail.com] On Behalf Of Timothée Maret
Sent: 16 January 2013 14:32
To: dev@sling.apache.org
Subject: User to tenant mapping
Hi,
I have been using the sling tenant recently and although the tenant path matcher configuration is flexbile, the user to tenant resolution mechanism enforces to organize the users following a fixed structure where all the users must be under the tenantId root.
As an example:
/home/users/<tenantId>/bob
/us/alice
/fr/charles
This is not flexible enough, especially with enabling tenant support on legacy system where users location is already set.
I think there two approaches to improve that
* Based on group
Instead of being applied against the user home path, the regex could be applied against all the groups the user is a member of. Each tenant would be assigned to a default group and the first tenant.default-group/user.group match would define the user as being part of the group.
This offers the flexibility to store the user anywhere. However, the resolution would be undeterministic in cases where the user has more than one tenant group assigned. Moreover, this would interleave group and tenant support which sounds like a limitation in comparison to the path based approach.
* Based on property set in user home
Each user part of a tenant would have a property "tenantId" set which would map it to the tenant.
This implies a bit more maintenance but would offer the flexibility to store users anywhere as well as a separation between group and tenants.
To me, the property based is clearly the best way to go as it offers most flexibility in therms of group and user organization. Moreover, it could be implemented as an extension of the current design.
Basically, instead of only trying to match against the user home path, the TenantAdapterFactory could also look for the userHome + "tenantId" property path. If the property is present, then the value could be appended to the user home path and tried to be matched against the regex.
wdyt ?
Regards,
Timothee.