...
- A token covers a certain scope of access, tied to the client app. Assuming that user privileges vary throughout a repository, can OAuth tokens be used to effectively record user privileges?
- One token per application or per app user, is the OAuth model we see in the wild. Otherwise an app would have to know which token to use within some smaller context.
Implementation Questions
- Are OAuth mitigated operations subject to other access restrictions imposed on the user who authorized the token? (or the on-behalf-of user)
- Then ACL restrictions on the user would apply equally to the token-based requests they have authorized.
- Who will be able authorize third-party applications at the server's Resource Owner Authorization endpoint? (/authorize)
- fedora administrators
- who else?
- What scopes will govern token access?
- on behalf of user X (or security principal X)
- set of permitted actions (read, write) (Note that JCR 2.0 privilege discovery might align well with OAuth scopes.)
- within repository path /A/B/C
- between now and X months hence
- Which scopes are optional and which are mandatory, for whom?
- Do admins get to give away global permissions to apps?
- Are tokens authorized by normal users restricted to their current permissions?
- How much access can a single OAuth token cover? Can they be patched or modified after authorization to cover more cases?
...
- Support a fedora admin container role - Reasonable performance is important when intercepting every request. In addition to performance optimizations, the PEP should allow a bypass method for requests considered pre-authorized for all repository actions by virtue of some container role.
- Repository admin should be able to update access policy on his/her items
- Content owner should be able to update access policy on his/her items
- Who is the content owner? Is this a feature of the RBAC profile (owner as role) or a general authorization feature? Or both? (I think owner is probably a role)
- If we define a Fedora owner property, then we have to restrict updates to it as well.
- Support permission of specific actions, such as patch SPARQL update, as well as generic actions, like create, read, update and delete.
- Fedora API may not be granular enough in all cases, modifyDatastreams is in the API, but some of the datastreams might be restricted.
- Access should be controlled when an item is searched.
- Need specifics here. What metadata is protected on these items? How will we facilitate end-user authorization requests without providing some metadata?
- Access should be controlled when resource is requested directly
- Allow resources to be protected at the jcr node level
- Do we want policy language to reflect the Fedora API or the Fedora object model?
- The object model. The object model is the common set of notions for the entire repository. It is entirely plausible that parties will introduce new APIs, and we don't want to incur or inflict the cost of rewriting au th code. ( A. Soroka )
- Do we want policy language to reflect the Fedora API or the Fedora object model?
- Allow users to authenticate via Shibboleth, CAS, LDAP.
- Yes, but this should be a container concern. It would be great if LDAP user metadata could be packaged as SAML for the PEP.
- Support for users granting permissions to applications via OAuth. (see below)
- Support for decision caching ( JBoss XACML decision cache )
OAuth Support
Users that wish to authorize other applications to act on their behalf will be able to do so via the OAuth endpoint. So policy-based restrictions on the user role will apply equally to token-based requests.
Which is a requirement?
- The application using the OAuth can never exceed the current authorizations of the user that created the token. (Permission implies the ability to grant permission to an app.)
- or
- The OAuth token can only be authorized by an "owner", i.e. someone authorized to grant permissions generally.
Users will want to limit the scope within which they authorize these applications:
- to particular parts of the repository hierarchy
- to a particular set of well defined actions
- to a time frame
...
Reference Profile: Role-Based Access Control (RBAC)
One way to implement XACML authorization is to write policies around user roles, i.e. recognizable sets of permissions. This separates the determination of user roles from the policies that determine permitted actions. Fedora 4 beta ships with a RBAC reference profile. It consists of a set of role-based XACML policies and metadata conventions for assigning roles within the repository on the basis of the authenticated request attributes.
...