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. >
