Isn't Shiro the basis of Stormpath? Perhaps you could gain some insight into using it in multi-tenant mode by consulting their developer guide:
http://docs.stormpath.com/rest/product-guide/#.U8acg8vn8m8 On Jul 16, 2014 8:22 AM, "Todd Nine" <[email protected]> wrote: > We've used Shrio successfully in our multi tenant application very > successfully. > > http://usergrid.incubator.apache.org/ > > Not sure if it's relevant to your use case, but we organize everything > into a hierarchy on the URL structure. > > /org/app/collection/... > > We then make heavy use of wildcards in our permissions. /org/app/** for > admins. For restricted data (say user private data) we use permissions of > /org/app/users/me/**. > > Take a look, and let me know if you have any questions. > > Todd > > On Tue, Jul 15, 2014 at 2:21 PM, rawc <[email protected]> wrote: > >> We have a multi-tenant application that provides a REST API and we are >> using >> Shiro for authentication and are trying to figure out the best way to use >> Shiro for authorization as well but it doesn't seem as though Shiro's >> authorization model supports our needs. I'll explain our needs below and >> hopefully someone will be able to chime in and let us know if Shiro >> supports >> our use case (which doesn't seem to be the case after looking through >> Shiro's source code but please correct me on this if I am wrong). >> >> Our REST API supports access to resources which for the sake of simplicity >> will just be referred to generically as 'resource' (e.g. /api/resource/1, >> /api/resource/2, etc). Since our application is a multi-tenant >> application, >> each client will have access to a different set of 'resources' and the set >> of 'resources' a client has access to is potentially quite large. In our >> REST API endpoint, we'd like to have an authorization check to make sure a >> client is authorized to access a particular 'resource' (e.g. something >> along >> the lines of 'subject.checkPermission("resource:*:1")' ). This permission >> check will eventually hit the doGetAuthorizationInfo() method of the realm >> implementation which retrieves the entire list of permissions for the >> subject principal. This seems highly inefficient as each client of our >> application will have access to thousands of 'resources'. With caching, >> the >> load on the database for doing a permission check would be reduced, but >> this >> seems really inefficient to have a simple checkPermission() compared >> against >> the entire list of resources/permissions that a client has access to. To >> make things more complicated, clients are able to add and delete >> 'resources' >> as needed and I'm not sure what implications this would have with Shiro's >> permission cache (how it determines when the cache is outdated and how >> often >> it would have to completely reload the list of permissions again in the >> realm's doGetAuthorizationInfo() method). >> >> Can Shiro handle this type of authorization scenario? Are we approaching >> this wrong? Is there a different way of approaching this than what I've >> explained above? When we do an instance level authorization check we'd >> really like Shiro to eventually run a database query that would check to >> see >> if a client/user has access to the specific resource (our data model >> implicitly defines these permissions, they are not explicitly defined in a >> permissions table) but the Shiro framework and API's just don't seem to be >> setup for this type of scenario. Any help is appreciated, thanks. >> >> >> >> -- >> View this message in context: >> http://shiro-user.582556.n2.nabble.com/Shiro-Authorization-with-Large-Sets-of-Permissions-in-Multi-Tenant-Application-tp7580085.html >> Sent from the Shiro User mailing list archive at Nabble.com. >> > >
