next up previous contents
Next: 4.3.3 Do I have Up: 4.3 Administrator Previous: 4.3.1 What are the

4.3.2 How to use the access control mechanism?

 

Extended Question:
Christoph Haenle19: ``I got stuck reading chapter 15 of the Corba Security Spec (Nov '96). I wonder if Corba's ACL scheme can really provide access control on a per method and per user grain. At least I can't see from the spec how this could be accomplished.

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)



*main::open_tags
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



*main::open_tags
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?''

Bob Burt
(October, 1998)20 : Try this:


*main::open_tags
Privilege attribute Granted Rights
access_id:alice get, set, do_m1
access_id:bob get, set, do_m2





*main::open_tags
Required Rights Operation
do_m1 m1
do_m2 m2



Gerald Brose
(October, 1998)21 : That will do only for that particular situation, but the basic problem still remains: the default CORBA DomainAccess Policy scales neither up nor down! It does not scale down (meaning: provides fine-grained access control on a per-user/per-object/per-method basis) because there is no way to grant rights to access individual objects within a domain. As a consequence, you will have to manage a large number of very small domains each containing only one object of a particular type.

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.


next up previous contents
Next: 4.3.3 Do I have Up: 4.3 Administrator Previous: 4.3.1 What are the