Authentication with huge number of entites

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Authentication with huge number of entites

Michelle
We are using Shiro for Authetication and Authorization in our Web Application. Now we are facing huge performance issues and looking for a solution. Possible solutions are not working with the current implementation of our autorization checks.
Our application has two parts of users: internals (is allowed to read everything) and customers (is only allowed to read data that are related to the own customer). As the assignment of users to customers may change, we have permissions like 'product:read:restricted' instead of entity level permissions like 'product:read:1'. Our realm implemenation does an on-the-fly check of customer-matching when the user has a "resticted" - permission.
Now we have about 5000 products in our database. In case a customers logs in, we are loading all 5000 products into memory and let shiro check the authorization. Most of the restricted users are only authorized for less than 10 products.
Our goal now is to not load everything before checking the authorization (advantages: less objects in memory, and the possibility of paging etc for users that are authorized to see more).
Putting our authorization checks in our query would work, so we would load less objects. But the disadvantage is, that the rules for authorization are in diffenrent places: Inside the DAO (query generation) and in our Realm-Implementation. Does anyone have an idea, how we might solve our problem (load less entities, check the authorization before having thousands of entities in memory), without duplicating our rules, or even using shiro for that?
Many thanks for any ideas, Michelle
Reply | Threaded
Open this post in threaded view
|

Re: Authentication with huge number of entites

armandoxxx
This post was updated on .
This is the root of all evil for instance base permission checks..

our problem was ...  user had 2000 IDs in the permission ... so writing permission with 2000 Ids in the target was not an option.

First thing we did was:
First we did was use mongoDb for fast read, store of (instance - per user permissions) ... so realms would load data from there .. (caching)

The second thing we did was to override isPermitted() method to check targets of permissions and introduced target resolvers ...

example  permission was "products:list:PRODUCT_TARGET_RESOLVER" ...  

PRODUCT_TARGET_RESOLVER - became constant to to load target resolver, which checked instance permissions ...

it was a dirty job since Shiro does not support target resolvers ... so we extended Shiro to support it ...

How you implement it is up to you ...

Regards

Armando





Reply | Threaded
Open this post in threaded view
|

Re: Authentication with huge number of entites

Brian Demers
Cool!

Any chance you can post an example of your target resolver?

On Thu, Sep 29, 2016 at 7:08 AM, armandoxxx <[hidden email]> wrote:
This is the root of all evil for instance base permission checks..

our problem was ...  that user had 2000 IDs in the permission ... so writing
permission with 2000 Ids in the target was not an option.

First thing we did was:
First we did was use mongoDb for fast read, store of (instance - per user
permissions) ... so realms would load data from there .. (caching)

The second thing we did was to override isPermitted() method to check
targets of permissions and introduced target resolvers ...

example  permission was "products:list:PRODUCT_TARGET_RESOLVER" ...

PRODUCT_TARGET_RESOLVER - became constant to to load target resolver, which
checked instance permissions ...

it was a dirty job since Shiro does not support target resolvers ... so we
extended Shiro to support it ...

How you implement it is up to you ...

Regards

Armando









--
View this message in context: http://shiro-user.582556.n2.nabble.com/Authentication-with-huge-number-of-entites-tp7581305p7581306.html
Sent from the Shiro User mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Authentication with huge number of entites

Rob Young
Seconded, I'd be interested see what you've done.  This whole email thread has been super interesting, I need to re-read it when I've had a lot more coffee and it will sink in. 

On Thu, Sep 29, 2016 at 9:25 AM, Brian Demers <[hidden email]> wrote:
Cool!

Any chance you can post an example of your target resolver?

On Thu, Sep 29, 2016 at 7:08 AM, armandoxxx <[hidden email]> wrote:
This is the root of all evil for instance base permission checks..

our problem was ...  that user had 2000 IDs in the permission ... so writing
permission with 2000 Ids in the target was not an option.

First thing we did was:
First we did was use mongoDb for fast read, store of (instance - per user
permissions) ... so realms would load data from there .. (caching)

The second thing we did was to override isPermitted() method to check
targets of permissions and introduced target resolvers ...

example  permission was "products:list:PRODUCT_TARGET_RESOLVER" ...

PRODUCT_TARGET_RESOLVER - became constant to to load target resolver, which
checked instance permissions ...

it was a dirty job since Shiro does not support target resolvers ... so we
extended Shiro to support it ...

How you implement it is up to you ...

Regards

Armando









--
View this message in context: http://shiro-user.582556.n2.nabble.com/Authentication-with-huge-number-of-entites-tp7581305p7581306.html
Sent from the Shiro User mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Authentication with huge number of entites

armandoxxx
This post was updated on .
In reply to this post by Brian Demers
Hey man .. I've checked our code and I it's total foobar of it ...
it works but we only used it once (will remove it, now that I saw it) ... so from what I saw (what we implemented afterwards) we are creating instance permissions on the fly when creating record instances ...

let me elaborate:
user creates a record (product, document, ...) ... after we store on our record in storage (db, mongo, etc ... )  we call our SecurityUtils.generatePermission(object, owner); to create instance permissions for owner or other ppl eg. security entities in the system that can have permission for this record ...

we also implemented Realms to load these permissions .. and there we have it ... instance based permission ... the Shiro way ...
our permission is like ... product:view:PRODUCT_UUID << and instnace permission is stored on security entity ...
That's why we use no-sql storage.

Sorry for earlier kinda misleading post .. our code was written and rewritten long time ago so I forgot about it ... I just remembered the ideas ...

Kind regards

Armando

Reply | Threaded
Open this post in threaded view
|

Re: Authentication with huge number of entites

armandoxxx
This post was updated on .
and the benefit of the new instance object permissions over "TARGET RESOLVER" idea is:

- SHIRO WAY
- NO HACKING AND EXTENDING SHIRO
- NO BLOATWARE CODE TO DO MAGIC

regards

Armando
Reply | Threaded
Open this post in threaded view
|

Re: Authentication with huge number of entites

armandoxxx
what did you decide then ?

regards

Armando