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: [email protected] [mailto:[email protected]] On Behalf Of > Timothée Maret > Sent: 16 January 2013 14:32 > To: [email protected] > 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.
