...
- Researcher control the polices on their own objects
- Distributed authentication and authorization
- University of North Carolina at Chapel Hill
- Unified Authorization
- Setting Individual Permissions
- Yale University
- Fedora managing access conditions
- Programmers use API for access condition support in external systems, i.e. HydraTitle (goal)
- Applications use API for updating access conditions stored in Fedora
Authentication
In general authentication is handled by the servlet container, i.e. Tomcat. Authenticated requests will arrive at Fedora servlets with a non-null values for getRemoteUser() and getUserPrincipal().
Fedora can authorize actions on the basis of user name, but may access may also hinge on additional principals that are specific to an organization. These include attributes coming into the request from Shibboleth, LDAP, etc.. Arbitrary principals can be added to Fedora requests by implementing the PrincipalFactory interface. A PrincipalFactory examines requests and returns a set of additional principals for authorization. Example principals include a named IP range, an affiliation or group from a Shibboleth SP header, principals extracted from a SAML payload, etc.. Fedora provides a configurable HeaderPrincipalFactory that extracts principals from headers.
Principal Discovery
Principals used in ACLs
Authorization (DRAFT)
Fedora 4 will intercept JCR operations in order to enforce policies that are based on the Fedora object model and other node characteristics. While a single Fedora API call may span several JCR operations, these will be joined by a JCR transaction and may all fail together due to a permission check.
...