Versions Compared

Old Version 7

changes.mady.by.user Scott Prater

Saved on

compared with

New Version 8

changes.mady.by.user Greg Jansen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Researcher control the polices on their own objects
  2. Distributed authentication and authorization
  3. University of North Carolina at Chapel Hill
    1. Unified Authorization
    2. Setting Individual Permissions
  4. Yale University
    1. Fedora managing access conditions 
    2. Programmers use API for access condition support in external systems, i.e. HydraTitle (goal)
    3. Applications use API for updating access conditions stored in Fedora
  5. University of Wisconsin - Madison
    1. External authentication and authorization

User Authentication

In general User authentication is generally handled by the servlet Servlet container, i.e. Tomcat or Jetty. Authenticated requests will arrive at Fedora servlets with a non-null values for getRemoteUser() and getUserPrincipal().

Users authenticated in this way will have user roles of either fedoraUser or fedoraAdmin.

  • fedoraAdmin - Grants blanket permissions to the the Fedora repository
  • fedoraUser - Grants permissions that are specific to the user or their principals, see authorization below.

Additional Security Principals

Fedora can authorize actions on the basis of a user name, but may access . Access may also hinge on additional security principals that are specific to an organization. These include principals are often based on attributes coming into with the request from Shibboleth, LDAP, CAS, etc.. Arbitrary Additional principals can be added to supported in Fedora requests authorization by implementing the PrincipalFactory interface. A PrincipalFactory examines Servlet requests and returns a set of additional principals for authorization. Example principals might include a named IP range, an affiliation or group from a Shibboleth SP header, principals extracted from a SAML payloadpayloads, etc.. Fedora provides a configurable HeaderPrincipalFactory that extracts principals from headers.

Authentication of Third-Party Applications (OAuth)

Applications can be authenticated by means of token credentials delivered through the OAuth protocol. A user with the fedoraAdmin role may authorize application access without any limits scope, including access equivalent to the fedoraAdmin role.

Principal Discovery

A user with the fedoraUser role can only grant tokens within a scope that is limited by their own user credentials, since the application will only be able to act on their behalf. For specifics see the OAuth section below.

Establishing JCR Sessions

JCR sessions are tied to every Fedora REST request by means of an InjectedSession annotation on resources. This annotation will bring in a JCR Session from a SessionProvider that in turns get the Session from a SessionFactory. 

In Fedora transactions a JCR Session saved in the transaction. Sessions in transactions will remain open until the transaction is closed or the maximum time between requests is reached.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.

...

A custom SecurityContext class can implement the existing AuthorizationProvider  or AdvancedAuthorizationProvider interfaces to implement specialized security checks through the hasPermission method. 

Principal Discovery

Principals used in ACLs

ModeShape has a pending pull request that implements part of the Access Control spec from JCR 2.0 (MODE-1920). Their implementation includes defined internal node properties and API for manipulating access control lists in the JCR repository. These are features of objects that are only accessed by clients through the AccessControlManager API.

...