Page tree

Old Release

This documentation covers an old version of Fedora. Looking for another version? See all documentation.

Skip to end of metadata
Go to start of metadata

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

IDDataTypeSourceIn Request?Notes
urn:oasis:names:tc:xacml:1.0:subject:subject-idstringuser principalYes 
urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifierstringTBD name-space for the subject-id
urn:oasis:names:tc:xacml:1.0:subject:request-time AuthZ delegateYestime when this action was requested
urn:oasis:names:tc:xacml:1.0:subject:session-start-time ModeShape sessionYestime when Fedora transaction began
urn:oasis:names:tc:xacml:2.0:subject:groupstringall principals except userYesextensible via Principal Factory
fcrepo-xacml:subject-rolestringeffective access rolesYes

Fedora access roles for this user/group†

XACML Role-Based Access Control Profile

urn:oasis:names:tc:xacml:1.0:subject:authn-locality:authentication-methodstringTBDYeswhat style of AuthN? (OAuth/Tomcat/Shibboleth)
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:ip-addressstringTBDYesaddress of authenticating agent:
urn:oasis:names:tc:xacml:1.0:subject:authn-locality:dns-namestringTBDYesSee above description of ip-address.

† Hydra rights metadata may be dynamically crosswalked to Fedora roles via a sequencer.

Action Attributes

IDData TypeSourceIn Request?Notes
urn:oasis:names:tc:xacml:1.0:action:action-idstringModeShape actionYesSee ModeShapePermissions list
urn:oasis:names:tc:xacml:1.0:action:action-namespacestringpresetYesA 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.

IDData TypeSourceIn Request?Notes
urn:oasis:names:tc:xacml:1.0:resource:resource-idstringFedora pathYesThe full Fedora path to the resource or propery (with extra hierarchy compressed away)


URIFedora URIYesFedora graph subject URI for this resource
urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-selfstringFedora pathYesSet of paths for this resource and its ancestors
fcrepo-xacml:resource-parentstringFedora pathYesPath 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-ancestorstringFedora pathYesSet of paths of all ancestor resources
fcrepo-xacml:resource-workspacestringModeShape sessionYesName of the workspace
urn:oasis:names:tc:xacml:1.0:resource:scopestringAuthZ DelegateYes

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:

IDData TypeSourceIn Request?Notes property (via RDF property)NoPrimary Types and mixin types defined in CNDs will be returned in this attribute


Environment Attributes

IDData TypeSourceIn Request?Notes
urn:oasis:names:tc:xacml:1.0:environment:current-timetimeAuthZ DelegateYes 
urn:oasis:names:tc:xacml:1.0:environment:current-datedateAuthZ DelegateYes 
urn:oasis:names:tc:xacml:1.0:environment:current-dateTimedateTimeAuthZ DelegateYes 
urn:fedora:xacml:2.0:environment:original-ip-addressstringrequest IP or headerYesthe IP of the original client (may be forwarded by a proxy application
  • No labels


  1. 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.

  2. Note that the standard attributes above must be sufficient to write policies that mimic the behavior of the Basic Roles AuthZ Delegate.

  3. 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.

  4. 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'. 


  5. 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:

    1. 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.