From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of David Kuehr-McLaren
Sent: Friday, February 22, 2008
6:47 PM
To: Higgins
(Trust Framework) Project developer discussions
Cc: 'Higgins
(Trust Framework) Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev]
Proposed update to higgins.owl (aka HOWL)
Are the access control attributes a reflection of what
I "can do" (I am bulding a GUI and I what to know what fields to grey
out as read only) or are the attributes part of a policy that can be set by the
application (set addBy), or are they policy to be used by applications to
enforce access?
The AC attributes are a reflection of what I “can do”.
You ask the Context what you can do, and you act (e.g. present a GUI)
appropriately. How the Context somehow decides what its policy is and sets
these attributes accordingly.
Getting
the list of permissions for an object (before an operation on an object
is performed) is something I should be able to query through the IdAS API.
Exactly right. I think we’re talking about a set of new
IContext methods to AT LEAST read these values.
GUI building is a primary
use case. The permisions query needs to accomodate relation/correlation
attributes of the data (Org tree, admin groups, self, friend).
I
also agree the access needs to be instance based including by type (Managers
can view salary for folks who are of type employee but not type contractor).
David
"Jim Sermersheim"
<jimse@xxxxxxxxxx>
Sent
by: higgins-dev-bounces@xxxxxxxxxxx
02/22/2008 09:17 AM
Please
respond to
"Higgins \(Trust
Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
|
|
To
|
"'Higgins
(Trust Framework) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re: [higgins-dev] Proposed update to
higgins.owl (aka HOWL)
|
|
If I'm reading the
higgins.owl correctly, it seems like the stab at access control is to allow one
to put access control statements on model elements. For example, say we
have a model element for the "homeAddress" attribute. One could
control write access to the "homeAddress" attribute by placing upon
its model element an "addBy" specifier which names the node
identifier(s) that are allowed to write to instances of that attribute.
So, (I've said this before) I worry
that this is so inadequate that it will only serve to frustrate people.
It only works on the global scale -- I can't control access to attributes
on a per-node instance level. In other words, I can't say that my manager
has write access to my "salary" attribute. without granting him the
same access to *everyone's* salary attribute.
If instead (and this
is only one suggestion) we allowed access control statements to be made on the
resources they apply to, we could apply them to specific instances of things.
This wouldn't preclude us from making global statements. That could
be done by allowing access control made on the Context instance to apply
globally within the context. I'm sure there are even better ideas than
this.
Jim
>>> "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>
02/20/08 4:43 PM >>>
Attached is a
proposed update to higgins.owl along with two example files. I’m keeping
this out of the SVN until the 1.0.0 branch is done. The changes are summarized
here: http://wiki.eclipse.org/HOWL_Update. Other than endless refactoring to align
what we’re doing with best practices and other standards related to RDF,
it includes experimental support for a proposed simple access control policy
_expression_.
I have also attached
a sample test person.owl ontology that a CP might use, and an example of simple
instance data here: person-example.owl.
[Sergey this is the
update that I mentioned I was working on today]
-Paul
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev