If I got it right, individuals have a bunch of privilege attributes such as access_id, group, security clearance, role, etc. The administrator can grant rights to those attributes, for example rights to call read-methods (get), write-methods (set), or management-methods (manage). The DomainAccessPolicy object stores all this security data in a table, such as (simplified)
Privilege attribute | Granted Rights |
access_id:alice | get, set |
access_id:bob | get, set |
On the target side, a "RequiredRights" table exists, specifying which rights are required for each method. For example
Required Rights | Operation |
get | m1 |
get | m2 |
Now, because Alice holds get (and the set) right, she can call both methods. How could we specify get-permission on m1 for Alice, and on m2 for Bob, but no permission on m1 for Bob and on m2 for Alice?''
Privilege attribute | Granted Rights |
access_id:alice | get, set, do_m1 |
access_id:bob | get, set, do_m2 |
Required Rights | Operation |
do_m1 | m1 |
do_m2 | m2 |
On the other hand, the scheme does not scale up to large numbers of users (pricipals) and different object types, because the number of different combinations of granted/required rights is finite, so in order to avoid "rights clashes" like the one outlined in the first posting, you will again have to restrict your way of writing policies to relatively small domains - which is inconvenient if your policies happen to apply to large number of objects and principals. All in all, I'd say that there are quite a few limits in that paricular access model.