Skip to main content

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

 

Back to the top