Versions Compared

Key

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

...

All requests to the JCR repository that underlies Fedora come through a JCR Session. The JCR Session supplies results from JCR authentication and contain security context that allows the repository with security credentials that are used to make the most granular Fedora authorization decisions downstream. 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 During Fedora transactions a JCR Session saved in with the transaction. Sessions in transactions will remain open until the transaction is closed or the maximum time between requests is reached.

JCR Session creation involves a second authentication step, authentication is based on ServletCredentials that are passed through from the REST endpoint. The place to start looking at this is the SessionFactory, which retrieves the transaction session or formulates a repository login attempt from the servlet request. Repository logins in ModeShape are based on a extensible credentials object. In ModeShape logins may be implemented in multiple authentication providersby many implementations of an AuthenticationProvider interface. Fedora includes an authentication provider ServletAuthenticationProvider that checks requests for a proper Fedora user role of either fedoraUser or fedoraAdmin before permitting Session creation.

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.

...