Shiro Authorization with Large Sets of Permissions in Multi-Tenant Application

[rawc <ra...@gmail.com>]

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.

Re: Shiro Authorization with Large Sets of Permissions in Multi-Tenant Application

["M.C. Wilson" <ni...@gmail.com>]

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" <tn...@apigee.com> 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 <ra...@gmail.com> 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.
>>
>
>

Re: Shiro Authorization with Large Sets of Permissions in Multi-Tenant Application

[Todd Nine <tn...@apigee.com>]

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 <ra...@gmail.com> 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.
>