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 15:57, 3 July 2008 by Paul.socialphysics.org (Talk | contribs) (Revised Access Control Policy representation)

{{#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
  • 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)
  • However, in parallel I (Paul) have been thinking that 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.

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)
  • Need to discuss this with the Higgins team to see if this is a good way to handle this.

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