Hi Angela, The second PoC [1][2] passes Oak Tests and works (as far as I have tested) in Sling. It hides parts of the content tree not within the current tenant from JCR and hence Sling. It does this for all sessions including administrative and internal sessions. The shared parts of the tree remain shared, and it does not hide the tree below the Root and Tree level within Oak. The one limitation I can see is that child node counts will not be correct as they are performed inside the NodeBuilder.
The patch is smaller, with no security and permissions related changes. I am also using an attribute in AuthInfo to specify the tenant ID at login which eliminates other changes. In this version, no API/SPIs have been changed. 1 new SPI is introduced but mainly for cleanliness rather than real necessity. I will start on the third PoC next. Best Regards Ian 1 https://github.com/ieb/jackrabbit-oak/tree/tenant2 2 https://github.com/ieb/sling/tree/tenant2 On 22 May 2015 at 09:10, Ian Boston <i...@tfd.co.uk> wrote: > Hi, > > On 21 May 2015 at 19:40, Angela Schreiber <anch...@adobe.com> wrote: > >> hi ian >> >> sorry, if my reply looked harsh to you. >> > > no problem. Not being a committer, there is little point in producing > something that you don't like and then ask for it to be included. That goes > down the route of patch > /dev/null, wasting everyones time. > > >> >> i really don't care about the package names of a multi-tenancy >> POV :-) my take is that we get all security concerns (and a decent) >> content structure for free, if we managed to introduce the tenant >> separation above the Oak Root or JCR root node. >> >> not sure i fully understand the very details of your last summary >> but it seems to be closer to what i envision: >> >> i could think of a tenant separation even above the Oak Root >> and thus not having to think about the tenants when Oak Tree(s) >> come into the game. >> >> in other words: after having obtained the ContentSession >> and the Root object therein, you already had a totally isolated >> tenant, with a regular (JCR) root node, a separate user tree, >> a separate admin-user (having administrative-access just on that >> Root/tenant), it's own permission evaluation, a unique-indices, >> and jcr:system... everything for just that very tenant. > > > This is what my second PoC does, with a minor modification, only because I > hadn't thought of going below the Root/Tree level into the NodeBuilder. I > can try that in a third PoC once I get the second working. > > The minor modification is to give the MutableRoot a Tenant interface > implementation which evaluates if a new Tree object is would be foreign to > the tenant or not. If foreign the Tree is not created. The patch, so far, > is considerably smaller than the first PoC, but still modifies all Tree and > Root implementations. No changes were required to the Sling patch. > > I dont think it will isolate unique-indexes and jcr:system, and there are > some issues where direct access to the NodeBuilder is performed, like child > counts. > > IIUC a third PoC would go one level deeper and make each MutableRoot > contain different content based on tenantId. I can look at that as well. > There are some questions on how the content gets created for a tenant and > how shared content gets added to a root tree, but I suspect that will all > become clear when I read through how Trees get loaded. > > >> > > >> from an Oak/JCR perspective there was in such a setup no >> way to cross the tenant boundary and each tenant behaved >> from security point of view like an Oak repo now. so, it >> was only if you looked at the persistence layer that there >> were multiple tenants. >> > > agreed. > > >> >> that's my architectural vision of a multi-tenant oak repository >> without having a POC at hand. and obviously still a lot of >> question marks here and there ... :-) >> >> let's organise a meeting/call to also have the other team >> members on board. >> > > I have a meeting today, where that will come up, but best to have > something concrete to look at in advance rather than a growing workload of > questions and no time to answer them. > > Best Regards > Ian > > >> >> kind regards >> angela >> >> >> >> On 21/05/15 19:41, "Ian Boston" <i...@tfd.co.uk> wrote: >> >> >Hi Angela, >> > >> > >> >On 21 May 2015 at 17:53, Angela Schreiber <anch...@adobe.com> wrote: >> > >> >> hi ian >> >> >> >> yes... that's what I am saying... >> > >> > >> >Ok, thats fine I guessed right this morning when I abandoned my work in >> >progress. >> > >> > >> >> with a few correction, >> >> where i you might have got me wrong: >> >> >> >> 1) >> >> i don't think we should use JCR workspaces for the multi-tenancy >> >> but rather aim for 'similar' concept with multi-tenancy setup on Oak, >> >> where each tenants gets it's own root-node and everything below >> >> without the troublesome parts (multitenancy-wise) when it comes >> >> to JCR workspaces (e.g. shared version store). >> >> >> >> that would obviously also required a POC as there are for sure >> >> things that need a closer look... but IMHO this would be a >> >> promising approach that would allow for a real/proper threat >> >> boundary between tenants from a security point of view. >> >> >> >> apart from the trust boundary we could just get rid of those terrible >> >> multiple tenant-setups spread throughout the repository content, >> >> which are to become unmanageable with more people trying to make >> >> their app multi-tenant enabled. >> >> >> > >> >agreed, I started a new branch along those lines, which I just finished >> >with the refactor. It "taints" Root implementations and Tree >> >implementations with the tenant and asserts the validity of child >> >instances >> >when adding more to a tainted tree. >> > >> >In one sense each Root is different, but by tainting it allows all >> tainted >> >roots to share common areas of the Tree rather than having to know what >> to >> >mount and how. >> > >> >Its not committed, as I haven't proven it works yet. >> > >> > >> >> >> >> 2) >> >> after all I think it would make more sense if you invested research >> >> and time in a real multi-tenancy setup at the node store level >> >> as described above than trying to fix the existing broken design. >> >> after all you started to work on oak already, right? just needed >> >> to step one level deeper... it's still oak-core :-) >> >> >> > >> >I was at the Root/Tree level already, but I could not see how admin was >> >bypassing that level, so I put more checks in the permissions >> >implementation, and admin still got past, hence asking for help on the >> >list. I have no desire to mess in any package with the word "security" in >> >it. >> > >> >There are some areas that I have doubts about, as many of the Validators >> >perform operations on Trees they create out of the blue not connected to >> >any session. For the moment I am giving them a system context and logging >> >the location. >> > >> > >> >> >> >> as you may know the security team recently had another session >> >> listing problems with the current setup and discussing how it >> >> would make sense from a security point of view. from the information >> >> it got there from my security-colleagues attending the Adobe internal >> >> multi-tenancy calls, i understood that the first next step of the >> >> mt-working-group would be to come up with a threat-model including >> >> tenants... maybe that was a misunderstanding? >> >> >> > >> >I am not aware of those meetings, I haven't been involved in the >> >mt-working-group for about 18 months as I have been dealing with >> >production, performance and upgrade issues. >> > >> >I was asked to implement a PoC 2 to 3 weeks ago. >> > >> > >> >> >> >> 3) >> >> maybe it would make sense to have internal call with the security >> >> team, to bring everyone on the same page both from a expected >> >> next steps and a security point of view. >> >> >> >> wdyt? >> >> >> > >> >agreed. >> >Best Regards >> >Ian >> > >> > >> >> >> >> kind regards >> >> angela >> >> >> >> >> >> On 21/05/15 11:09, "Ian Boston" <i...@tfd.co.uk> wrote: >> >> >> >> >Hi Angela, >> >> > >> >> >So you are saying that there is no point in pursuing this PoC at the >> >>Tree >> >> >level and I should stop what I am doing and wait for the Oak team to >> >> >implement Workspaces or some other low level mechanism which was >> closed >> >> >"later" in February 2013 ? >> >> > >> >> >I agree with everything you have said, having experienced first hand >> >>the >> >> >issues you have referenced, which is why I have been asked to work on >> >>this >> >> >PoC, in a personal branch, in a fork of Oak on GitHub. >> >> > >> >> >Best Regards >> >> >Ian >> >> > >> >> > >> >> >On 21 May 2015 at 09:25, Angela Schreiber <anch...@adobe.com> wrote: >> >> > >> >> >> Hi Ian >> >> >> >> >> >> The take of the security team with respect to multi-tenancy is: >> >> >> Don't try to put that on top of the repository with having the >> >> >> tenants present in one single JCR workspace. >> >> >> >> >> >> This is not sensible from a content structure point of view, >> >> >> a nightmare when it comes to maintenance and most importantly, >> >> >> you will not be able to properly secure it. Not only from a >> >> >> permission point of view but also from an application point of >> >> >> view... we had lengthy discussions about this in the past and >> >> >> also discussed this with an external security expert during >> >> >> our yearly security summit. We are pretty sure that it's not >> >> >> possible. >> >> >> >> >> >> So, I would really strongly recommend to not try to improve a >> >> >> broken design that is based on unjustifiable assumptions (such >> >> >> as e.g. it's only the "content"). >> >> >> >> >> >> Not sure how many years EFA have already been spent on this >> >> >> but the more people are trying to use the same concept in the >> >> >> same repository to make their application multi-tenancy-aware >> >> >> the worse it will become. >> >> >> >> >> >> I would rather invest the time to implement proper multi-tenancy >> >> >> with a true, real and complete threat boundary between tenants in >> the >> >> >> deepest layer (repository) and you will have all security issues >> >> >> solved once forever. Anything else won't work and is prone for >> >>massive >> >> >> troubles both from a development and from a legal point of view. >> >> >> >> >> >> Kind regards >> >> >> Angela >> >> >> >> >> >> On 21/05/15 10:08, "Ian Boston" <i...@tfd.co.uk> wrote: >> >> >> >> >> >> >Hi Angela, >> >> >> >Thank you for the pointer. >> >> >> >I assume the area of code that allows administrative users to >> bypass >> >> >>all >> >> >> >access control is [1], which gives gives that session [2] granting >> >> >> >everything without restriction. >> >> >> > >> >> >> >The use case is muti-tenancy. The PoC attempts to make Oak natively >> >> >>multi >> >> >> >tenant. The PoC does not specify configuration or setup. At present >> >>it >> >> >> >introduces a SPI [3] with a default implementation that restricts >> >> >>access >> >> >> >to >> >> >> >Oak paths by pattern. The PoC implementation blocks access to >> >> >> >/tenant/<tenantid>/**, if tenantid specified at ContentSession >> login >> >> >> >doesn't match <tenantid>. >> >> >> > >> >> >> >The PoC, running in Sling, tested with the Sling Explorer >> >>application >> >> >>and >> >> >> >Sling REST API requests works as far as I have tested except for >> the >> >> >>admin >> >> >> >user. I have not tested the impact on internal users as they also >> >>get >> >> >>[2]. >> >> >> >I also haven't tested the impact on users and groups if they are >> >>stored >> >> >> >under /tenant/<tenantid>/** >> >> >> > >> >> >> >The patch to Sling requires tenantid to be specified at login, by >> >>Host >> >> >> >header, or on localhost by a request parameter to enable testing. >> >> >>Without >> >> >> >the tenantid, login fails. >> >> >> > >> >> >> >Best Regards >> >> >> >Ian >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >1 >> >> >> >> >> >> >> >>>>>org.apache.jackrabbit.oak.security.authorization.permission.Permission >> >>>>>Pr >> >> >>>ov >> >> >> >iderImpl.isAdmin(Set<Principal>) >> >> >> >2 >> >> >> >> >> >> >> >>>>>org.apache.jackrabbit.oak.security.authorization.permission.AllPermiss >> >>>>>io >> >> >>>ns >> >> >> >3 >> >> >> > >> >> >> >> >> >> >> >> >> >> >> https://github.com/ieb/jackrabbit-oak/blob/tenant/oak-core/src/main/java/ >> >> >>o >> >> >> >> >>>rg/apache/jackrabbit/oak/spi/security/tenant/TenantControlManager.java >> >> >> > >> >> >> > >> >> >> >On 21 May 2015 at 08:13, Angela Schreiber <anch...@adobe.com> >> wrote: >> >> >> > >> >> >> >> hi ian >> >> >> >> >> >> >> >> please note that this is a configuration option that can >> >> >> >> be established for _any_ principal name. >> >> >> >> >> >> >> >> if you try to remove access for built-in system principals >> >> >> >> the repository will be completely broken. >> >> >> >> >> >> >> >> also i am planning to use exactly this configuration to >> >> >> >> make sure our internal _administrators_ group is treated >> >> >> >> exactly like the admin user for the very purpose that >> >> >> >> i seems impossible that our developers keep a correct >> >> >> >> permission setup... half a year after investing weeks >> >> >> >> in correcting the setup its broken again :-( >> >> >> >> >> >> >> >> in general i tend to question the use-case you are working >> >> >> >> on as it will most definitely come with vulnerabilities >> >> >> >> and will make the effective permission setup even more >> >> >> >> complicated to understand and impossible to debug/display >> >> >> >> in a running repository. >> >> >> >> >> >> >> >> kind regards >> >> >> >> angela >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 20/05/15 17:44, "Ian Boston" <i...@tfd.co.uk> wrote: >> >> >> >> >> >> >> >> >Hi, >> >> >> >> >I am attempting to implement a PoC in oak-core that hides parts >> >>of >> >> >>the >> >> >> >> >content tree from users based on additional information provided >> >> >>when >> >> >> >>the >> >> >> >> >session is established. I have a working PoC for normal users, >> >>but >> >> >> >>admin >> >> >> >> >users still get read-only access to the areas of the tree they >> >> >>should >> >> >> >>not >> >> >> >> >be able to see. >> >> >> >> > >> >> >> >> >Could someone give me some hints as to where admin bypasses the >> >> >>access >> >> >> >> >control enforced by [1] and [2] ? >> >> >> >> > >> >> >> >> >Best Regards >> >> >> >> >Ian >> >> >> >> > >> >> >> >> >1 >> >> >> >> >> >> >> >> >> >> >> >>>>>>>org.apache.jackrabbit.oak.security.authorization.permission.Permissi >> >>>>>>>on >> >> >>>>>Pr >> >> >> >>>ov >> >> >> >> >iderImpl >> >> >> >> >2 >> >> >> >> >> >> >> >> >> >> >> >>>>>>>org.apache.jackrabbit.oak.security.authorization.permission.Compiled >> >>>>>>>Pe >> >> >>>>>rm >> >> >> >>>is >> >> >> >> >sionImpl >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
