Hi, @felix, yes thanks, I'll give it a try for SLING-2710 and post a patch there.
2013/1/16 Amit.. Gupta. <[email protected]> > > * 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: [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. > Regards, Timothee.
