Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

HOWL Update 1.1.103

Revision as of 11:49, 5 July 2008 by Paul.socialphysics.org (Talk | contribs) (See Also)

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

Version 1.1.103

Access Control Related Changes

Revised Access Control Policy representation

  • We have below two approaches to consider.
  • The question is what are the criteria to use to determine which is better
  • In the very very simple case shown below, it appears that the revised (lower) proposal is simpler (two arcs vs. three arcs)
  • But what we don't know which is simpler as the complexity scales up
  • We decided on the 7.3.2008 call to apply some use cases to each to see which, when these case are modeled, "look better" (less complex to manage)
  • In parallel I [Paul] have been considering that perhaps the paramount consideration is to minimize the total number of Policy Entities in a Context. The intuition is simply that having fewer of these Entities will be easier to managed all around. If this is the case, then in the event that use cases involve a single Policy Entity controlling multiple resource Entities with differing permissions on each, then the added flexibility of the the revised (lower below) proposal's arc structure will result in the fewest Policy Entities.

Original approach (circa 1.1.102):

Original-acp.png

Revised approach used in 1.1.103:

Revised-acp.png

Changes related to this change of representation

  • Delete the Operation class (and all subclasses)
  • Change higgins:operation into being an abstract super-property whose range is the protected resource.
  • Added higgins:read, higgins:add, higgins:modify, and higgins:delete properties (all sub-properties of the revised higgins:operation super-property).

New "managedBy" property

There is currently a problem with the access control constructs in 1.1.102. There is no way to know what Entity is permitted to manage (modify, delete, etc.) a given PolicyEntity. The proposal here is to add a "managedBy" property:

  • Added "managedBy" property (domain = Policy, range = Agent who is permitted to manage this Policy Entity)
  • We discussed this with the Higgins team on July 2 and it was suggested that we should try to use recursion instead--use Policy Entities to protect the Policy Entities.

Misc Changes

Simplification:

  • instead of including an explicit BlankEntity class in the data model, we simply say that Entities have at most one EntityId, not exactly one. The BlankEntity class has been eliminated.

See Also

Back to the top