4.3.2 How to use the access control mechanism?

 

Extended Question:

Christoph Haenle¹⁹: ``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)²⁰ : 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)²¹ : 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.