I looked into doing this once when I was told that our domain was this
size. (I was a new employee and later discovered that it wasn't this
large).
My first thought is that you should avoid thinking about
doGetAuthorizationInfo and implement isPermitted on the *Realm* yourself.
This will avoid you having to recalculate *everything* all the time,
although you will have to do your own caching.
My second thought is that trying to add the requested object to the
PrincipalCollection is a bad idea. This isn't what the PrincipalCollection
is meant for, and I foresee concurrency and data consistency issues.
On addressing the issue of needing the domain object, my first approach
would be to encode an "id" in the permission string, and have my Realm do
the same lookup - if there's a cache for these lookups that's shared
between the Realm and your user code, then the extra work should be
trivial. That would look something like this: "read:UP-123456:*",
"read:UP-123456:health-records", "update:UP-123456:disposition". (note
that i tried to use your examples w/o knowing very much at all about your
domain)
If this is not feasible, you could implement your own Permission class
- "RailcarPermission" for example. Then you could do:
SecurityManager.getSubject().isPermitted(new RailcarPermission("view",
myRailcarObject, "health-records")).
I believe that encoding the ID in the permission string will give you more
flexibility in the future, but which direction to go is really up to you.
-Jared
On Wed, Jul 17, 2013 at 10:48 AM, jmcginn13 <[email protected]> wrote:
> Hi,
>
> My scenario has a large number of rapidly changing permissions based on the
> data in my domain model. We also have a large and growing set of
> rules/policies for determining user permissions. The set of data objects
> and
> number of permissions is in the order of tens of millions. In some cases we
> need permissions down to the field level. The domain model changes at a
> high
> enough velocity (100's of thousands of updates / day at a minimum) that
> pre-calculating and storing the permissions doesn't seem very feasible.
> What
> I want to do to solve this is the following:
>
> Store in a in memory cache my identity database (the elements for my domain
> objects needed for permission determination)
> Encode my security policies/rules in business rules (i.e. Drools)
> When a user requests access to an entity I want to:
> * Load my object identity from my database
> * Execute my security ruleset to generate the applicable permissions for
> that user for the object being requested
> * Allow the client system use the "isPermitted" methods to see if the user
> has permission and react accordingly.
>
> A concrete example:
> The domain model is railcars. A limited example would be something like:
> Car ID - UP-123456
> Current Owner - GATX
> Current Handling Carrier - BNSF
> Current Repair Shop - NULL
> Current Shipper - DOWX
> Current Consignee - ECF
> Damaged/Defect Flag - N
> Component Recall Flag - N
> WILD Alert Flag - Y
> ... and so on
>
> The total data size is roughly 1.8 million railcars. There are other domain
> objects I'll be adding to this as well that have even larger data sets.
>
> Some example policies:
> If user is owner can see everything for car
> If user is handling carrier can see certain health records on the car
> If car is damaged and user is handling carrier can see everything on car
> and
> can update disposition on car
> ...
>
> Now to my problem. The dynamic permission generation requires both the user
> (PrincipalCollection) and the object being requested so that the
> doGetAuthorizationInfo of my realm can populate the rule engine with the
> objects it needs. My first thought is to add the object being requested to
> the principal collection, but I'm not sure what would be the best part of
> the API to extend to do this. Does anyone have experience with a similar
> scenario they can share with me?
>
> Thanks in advance
>
> John
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Handling-a-large-number-of-dynamic-permissions-tp7578918.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
