These are the standard attributes that are supplied by the Fedora XACML AuthZ Delegate. As a point of reference, here are the standard fedora attributes from the FeSL implementation of XACML.
Subject Attributes
| ID | DataType | Source | In Request? | Notes |
|---|---|---|---|---|
urn:oasis:names:tc:xacml:1.0:subject:subject-id | string | user principal | Yes | |
urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier | string | TBD | name-space for the subject-id | |
urn:oasis:names:tc:xacml:1.0:subject:request-time | AuthZ delegate | Yes | time when this action was requested | |
urn:oasis:names:tc:xacml:1.0:subject:session-start-time | ModeShape session | Yes | time when Fedora transaction began | |
urn:oasis:names:tc:xacml:2.0:subject:group | string | all principals except user | Yes | extensible via Principal Factory |
fcrepo-xacml:subject-role | string | effective access roles | Yes | Fedora access roles for this user/group† |
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:authentication-method | string | TBD | Yes | what style of AuthN? (OAuth/Tomcat/Shibboleth) |
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:ip-address | address of authenticating agent:
| |||
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:dns-name | string | TBD | Yes | See above description of ip-address. |
† Hydra rights metadata may be dynamically crosswalked to Fedora roles via a sequencer.
Action Attributes
| ID | Data Type | Source | In Request? | Notes |
|---|---|---|---|---|
urn:oasis:names:tc:xacml:1.0:action:action-id | string | ModeShape action | Yes | See ModeShapePermissions list |
urn:oasis:names:tc:xacml:1.0:action:action-namespace | string | preset | Yes | A TBD namespace referring to modeshape actions. |
Resource Attributes
Question: What kind of URI shall we use for pointing at resources in Fedora/ModeShape policies? This decision will mostly be of concern to ResourceAttributeFinders, since policies will not usually refer to individual resource IDs directly.
| ID | Data Type | Source | In Request? | Notes |
|---|---|---|---|---|
urn:oasis:names:tc:xacml:1.0:resource:resource-id | string | Fedora path | Yes | The full Fedora path to the resource or propery (with extra hierarchy compressed away) |
| ||||
urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self | ||||
fcrepo-xacml:resource-parent | string | Fedora path | Yes | Path of the parent of the resource (always an existing resource, in session if not saved to workspace) |
urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor | ||||
fcrepo-xacml:resource-workspace | string | ModeShape session | Yes | Name of the workspace |
urn:oasis:names:tc:xacml:1.0:resource:scope | string | AuthZ Delegate | Yes | If the action impacts child resources, then value will be "Descendants", otherwise it will be "Immediate". A "remove" is an example of such an action.‡ |
‡ Further research is needed to figure out the semantics of a ModeShape move operation and how policies shall be enforced.
RDF Predicates as Dynamic Resource Attributes
There are many RDF predicates that are available in the graph for Fedora resources. These include numerous properties like mime-type, binary size, and even checksum. Without trying to predict which of these will be useful in policies, Fedora XACML can reference any predicate URI as a resource attribute ID.
Here are some examples of these resource attributes:
| ID | Data Type | Source | In Request? | Notes |
|---|---|---|---|---|
| http://www.w3.org/1999/02/22-rdf-syntax-ns#type | URI | ModeShape property (via RDF property) | No | Primary Types and mixin types defined in CNDs will be returned in this attribute |
Environment Attributes
| ID | Data Type | Source | In Request? | Notes |
|---|---|---|---|---|
urn:oasis:names:tc:xacml:1.0:environment:current-time | time | AuthZ Delegate | Yes | |
urn:oasis:names:tc:xacml:1.0:environment:current-date | date | AuthZ Delegate | Yes | |
urn:oasis:names:tc:xacml:1.0:environment:current-dateTime | dateTime | AuthZ Delegate | Yes | |
urn:fedora:xacml:2.0:environment:original-ip-address | string | request IP or header | Yes | the IP of the original client (may be forwarded by a proxy application |
6 Comments
Greg Jansen
Not sure about authn-locality attributes. Documentation says that they "indicate the location where authentication credentials were activated" and correspond with certain entities in SAML. These attributes may not be the best way to express client IP.
Might be better to use an environment attribute to express client ip address.
Greg Jansen
Note that the standard attributes above must be sufficient to write policies that mimic the behavior of the Basic Roles AuthZ Delegate.
Greg Jansen
I think there is a possibility of supporting arbitrary RDF properties as resource attributes. Attribute ID being the URI of the predicate. The resulting literal or resource would have to match the data type requested by the policy.. This would satisfy a number of use cases without requiring additional configuration beyond the XACML policies themselves.
Stefano Cossu
Is there a way in XACML to refer to a specific attribute name AND value that the user is attempting to set?
e.g. I want to allow only certain users to assign the mixin 'myns:dontMessWithThisMixin'.
Greg Jansen
Hey Stefano,
There is no way now to limit the permissions on the basis of the value being set. All our current enforcement happens behind a ModeShape API that does not give us that information in the callback method, i.e. for set_property action. You can certainly limit all the pertinent properties that make up that mix-in, but you cannot prevent assignment of that mix-in vs. other mix-ins. As you have taken on content modeling ahead of some of the rest of us, you are probably the first to try a mix-in-specific restriction.
For reference, we are implementing the AdvancedAuthorizationProvider interface for ModeShape as documented here: https://docs.jboss.org/author/display/MODE/Custom+authentication+providers
Stefano Cossu
Greg, thanks for the background information. It would be a nice feature to map attribute values at least for the special-case atribute rdf:type if the Modeshape interface allows it (through sessionAttributes?). It's something that we might look into if we find there is a strong need for it.
The most useful application I see for this approach is, since we are enforcing mixin-based rules, to prevent a user to associate a mixin with a node and subsequently getting locked out of that node because of restrictions tied to that mixin.