From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of David Kuehr-McLaren
Sent: Monday, February 25, 2008
12:28 PM
To: higgins-dev@xxxxxxxxxxx
Subject: RE: [higgins-dev]
Proposed update to higgins.owl (aka HOWL)
Paul,
Thanks.
I am still a little confused, because getBy, getBySelf, are expressions
of policy, and not an access check or a query of permissions granted. In the
GUI building example, when the application searches a context and gets back a
list of identifiers that meets the search, the application needs to know if the
authenticated user of the application can get/modify/delete attributes on the
resulting nodes. For each node and attribute, the application needs a
boolean response (e.g. get YES, modify NO) for each of the permissions. If the
application needs to interpret back getBy <list of Agents> and modifyBy
<list of Agents>, then the application has to evaluate if the user
authenticated to the context has a correlation to an agent in the list of
agents.
I
would expect the model to accommodate permissions granted at the
context/node/attribute level
add
boolean
delete
boolean
get
boolean
modify
boolean
There
is no need for the application to look at xxxBySelf, because that should
already been interpreted by the context's authorization provider.
Where
I see the need for xxxBy and relationship rules xxxBySelf is to build a generic
policy authoring tool for IdAS or a policy decision point that is external to
the context provider. This seems difficult to implement by the context
providers (not all providers have APIs for access policy). Perhaps a
policy import/export capabilities could/should be supported by the context
providers.
David
David
Kuehr-McLaren
Tivoli
Security - VMM & Tivoli Identity Manager
Identity
Integration Architecture
Master
Inventor
919.224.1960
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent
by: higgins-dev-bounces@xxxxxxxxxxx
02/24/2008
03:08 PM
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)
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