Contribute | Main Page

From FezWiki

FezACML History

During the early planning and design phases of Fez, the team realised temporary security control would be needed until Fedora 2.1 arrived with XACML support (at that stage an unknown timeframe). FezACML was designed to solve the urgent security needs, with the potential for it to be replaced by XACML controls once they had been implemented in the core Fedora system.

FezACML design: rules, roles, conditions

FezACML is designed around a simple rule creation based on roles. Those roles are granted to a user when they satisfy one of the conditions in a role-condition pair.

The Fez common roles are:

• Lister: Whether the users will be able to view an object in listings and search results. If no viewer security rights are set on the object it will be assumed anyone can list or search the object.
• Viewer: If no viewer security rights are set on the object it will be assumed anyone can view the object. If viewer role is granted to a user they will also gain the Lister role by default.
• Creator: Grants the user access to create child objects under this object. Gaining this role grants the Viewer role as well.
• Editor: Grants the user access to edit an object and child objects inheriting security. Gaining this role grants the Viewer role as well.
• Approver: Grants the user access to publish an object from the submission buffer. Gaining this role grants the Viewer role as well.

These roles are granted when a user’s attributes match against values in these possible attributes:

• Organisation Active Directory / LDAP group membership
• Organisation Active Directory / LDAP username
• Organisation Active Directory / LDAP distinguished name (Organisational Unit)
• Internal Fez groups
• Internal Fez usernames
• In AD/LDAP: whether the user is in the Active Directory / LDAP
• In Fez: whether the user is a user in the internal Fez user management system

With the release of Fez 1.2 the FezACML security model could also base rule conditions on the higher education standard eduPerson [HREF17] attributes, when the user logs in with Shibboleth [HREF26] authentication:

• eduPersonTargetedID: A unique, anonymous ID from the user’s Identity Provider
• eduPersonAffiliation: eg staff, student, faculty, alum, affiliate, employee (multiple)
• eduPersonScopedAffiliation: eg student@uf.edu.au, staff@uf.edu.au
• eduPersonPrimaryAffiliation: eg staff, student, faculty, alum, affiliate, employee (single)
• eduPersonOrgUnitDN: Will allow access to this role if any text matches eg Library text would match for value of ou=Library, o=The University of Fez (multiple)
• eduPersonPrimaryOrgUnitDN: eg Library

The security rule-set for a Fez Fedora object is saved in its own FezACML datastream. FezACML is designed so security can be inherited from parent hierarchy objects. This allows rules for an entire community or collection to be set in one place. If a collection or record belongs to more than one parent and is set to inherit security, a user can gain roles for that object from any of their authorisation matches in its parent object FezACML rules (thus achieving multiple security inheritance). Security can be set at any level of hierarchy from community, to collection, to record, even down to the datastream level (for managed content eg images, PDFs). For managed content datastreams the FezACML rules are saved in a datastream with a “FezACML_” prefix and then the filename as the suffix, without the file extension.

While this naming convention will probably stay with future versions of Fez the logic governing the relationship will be moved to be controlled by a REL-INT datastream instead. FezACML will also contain other security control rules concerning non-role-authorisation aspects for objects in future versions of Fez. For example for an image datastream (eg a TIFF image), the record creator will be able to watermark and add copyright statements to the preview and web display versions and define specific web and preview image format dimensions. Record creators can specify separate security for access to the archival (originally submitted) version of the file for image mime-type datastreams.

XACML: the future?

Initial performance problems with the Fedora XACML implementation [HREF20] and more recently other development priorities have delayed a study into replacing FezACML with XACML. During such a study the XACML engine will have to be able to handle security inheritance and at least match the performance and functionality of the FezACML security model before a migration will be assessed.

Another challenge is that XACML is lacking a strong GUI tool for editing security rules. Some basic prototypes exist in various stages but none are user friendly, even for IT administrators. The major benefit of moving to XACML is it has some standardisation and will (in theory) allow for cross-portability of Fedora objects between a Fez-Fedora repository and Fedora repositories governed by other front-ends. Although XACML is a form of standard, the uses for XACML attributes will vary between deployments. The ARROW [HREF19] project (with some participation from eScholarshipUQ) is in the process of creating a guideline for the use of XACML attributes. The finalisation of such a guideline would spur further action to move Fez to support XACML.