...
- Owner - This is a read/write role that also allows the user to assign roles to others.
- Content roles are stored on a Fedora object mixin node - authorization mechanism must enforce edit privileges on this node.
- Content roles are inherited from higher up in the tree of Fedora objects.
- New roles may be assigned lower in the tree of Fedora objects.
- Role inheritance can be blocked at any point in the tree.
- Content roles have no effect on the privileges granted to user roles (originating in container auth) or conferred by other means.
- Roles can be assigned to any security principal that is available in the Fedora security context.
- This can include things like a user, a named IP range, LDAP group or organizational affiliation.
- Can be based on Shibboleth supplied x.520 headers
- Are there useful CAS attributes other than username? Do CAS implementations use LDAP, for instance?
- You can also assign roles to the Everyone principal, present in every Fedora security context.
- Is Everyone anonymous? Or is there Everyone (that we know), and then Everyone (that we know) + Anyone (A. Soroka)
- We can do both. I think "everyone that we know" is a subset of "everyone". How does "authenticated users" sound?
- A query can retrieve all content roles assigned to an object or a principal.
...
- Do we support policies with additive permissions? (role B policy has all permissions of role A policy, plus...)
- Subtractive permissions (role B policy has all permissions of role A policy, minus...)
- Is this something that XACML can do for us, or something we would have to rig up? - Greg Jansen
- Set operations between roles? (role D can do what role A can do, except for what roles B or C can do)
- see above
- Provide examples of custom attributes being used in policies (a publication flag or embargo date, for instance)
...
This approach intercepts JAX-RS-supported HTTP requests and provide provides some form of policy enforcement around the API operation.
...