Paul, I just looked at the wiki and saw the part about managedBy. Could we just use a policy to do this as well?
Assume a brand new IdAS context exists with no policy entities. To me, this would imply that any authenticated user (even an anonymous user) has full access to everything. The first thing you'd do is create an entity to represent the "policy administrator" (don't forget it's password!). Next, create a policy entity (let's call it superPolicy for now) that governs all entites in the context (can we express that yet?). Also create a policy entity which grants the policy administrator modify access to the superPolicy entity (let's call this the policyAdminPolicy). Now change the superPolicy entity to disallow everyone all access to everything (or whatever you want your most restrictive default access control policy to be).
If we're able to express 1 subject, (N operation/resource) on a policy entry, then the policyAdminPolicy can be updated whenever a new policy entity is created such that the policy administrator has modify access to that new policy entity. It boils down to updating something different from what you're proposing, but it's more consistent.
The reason I think it might be important to maintain consistency is this:
Say we use the managedBy property on the policy entity. To me, this seems pretty simple, and straightforward. So simple and straightforward, I wonder why don't we just do this for all access control statements? That is to say, why not place the access control statements *on* the resources being protected? I'd want to know why I can't just put an "modifiableBy" property on mary's hatsize attribute, or on her entity which points to the subject being granted that permission.
>>> Paul Trevithick <paul@xxxxxxxxxxxxxxxxx> 07/02/08 4:33 PM >>>
|