Access Policies via Models

Title (Goal)Support Fedora 3-style object classes (content models) - Access Policies via Models
Primary ActorRepository architect & implementer 
ScopeData architecture and access
LevelHigh 
Story (A paragraph or two describing what happens)

As a repository manager,

  1. I can associate access policies to "content models"

Examples

  1. Given the myns:image object, I want to create some access policies that allow only users in imaging group to view and update that object.
  2. If a user adds the mymix:published_web mixin, access to that object, some of its properties, and the web_thumbnail, web_small and web_large datastreams is granted to web users. 
  3. If a user removes the mymix:published_web mixin, access to the object, all its properties and children is revoked for all web users.

4 Comments

  1. David Wilcox

    As of 4.0-Alpha-4, there are several ways to possible address this use case using the existing framework. It would be useful to discuss these options with the author, Stefano Cossu.

  2. Stefano Cossu

    Which options do I have to achieve this? 

    I haven't been able to look into XACML for Fedora 4 yet, which was my first guess; some examples would help figuring out a strategy.

    1. Andrew Woods

      Stefano Cossu, it sounds like the objective of this use case is to enable and disable permissions for members of the "imaging" group on certain resources. Is there any reason not to simply achieve this by using the existing AuthZ framework to change the access rights of the "imaging" group for the given resource? Do mixins need to play a role?

      1. Stefano Cossu

        Andrew,

        Actually our authZ needs are more complex. Some permissions should be calculated from the intersection and/or union of several properties. 

        E.g. the Imaging department should have r/w access to all images, except for some confidential ones created by some specific departments, which only few users in that department can view or edit.

        Also our CMS has more fine-grained access rules for some individual objects, and we want those object only be accessible by users trough our CMS; so we want to add a property (i.e. mixin relationship) that marks them as "CMS private" objects and specify restriction by using that parameter. 

        I haven't been able to actually test authZ since an issue with the indexer (https://www.pivotaltracker.com/story/show/64929156) currently breaks search in my client if I set up authentication, so I might not know all the pros and cons of assigning roles by hierarchy. It seems more useful and flexible to me to assign policies by properties though, and use node types or mixins as a conventional anchor for those policies (and of course, retaining the fine-grained control of assigning policies to individual nodes or trees). 

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.