[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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?
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. 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
