...
| Info | ||
|---|---|---|
| ||
In Development: Fedora ships with this simple principal factory that creates string-based security principals from request headers. This is useful in cases, like the Apache HTTP Shibboleth module, where additional attributes are supplied as request headers. |
...
* for future consideration: A user with the fedoraUser role could grant tokens within a scope that is limited by their own user id credentials. The application would be able to act on their behalf. One token per app user is the OAuth model we commonly see. Otherwise an app would have to track which token to use within some smaller context.
FAQ
- Are OAuth mitigated negotiated operations subject to the same access restrictions imposed on the user who authorized the token? (or the on-behalf-of user)
- Then ACL restrictions on the user would need to apply equally to the token-based requests they have authorizedThis will vary based on your authentication system. An OAuth token with on-behalf-of scope are limited to the access granted to that user, and their associated principals as retrieved by the configured principal factories. In other words, principal factories may bring more credentials into the security context. Depending upon your environment, this may or may not be equal to the access of the actual logged in user.
- Can an OAuth tokens be used as principals and assigned access roles within the repository?
- Yes, access tokens may be assigned roles within the repository. This is especially useful for limited application access to a subtree.
- How are scopes combined?
- Each scope imposes additional limitations upon the access granted to the token. So "read only" and "fedora administrator" combine to make a token that can read all the data in the repository. It doesn't make much sense to combine "on-behalf-of" with "fedora administrator" or "forward credentials" since the result token would effectively only have on-behalf-of X access.
...
Access Roles API
The access roles API is a Fedora module that allows you manage the assignment of access roles throughout the repository tree. For details, please see the Access Roles Module.
...
| Info | ||
|---|---|---|
| ||
In Development: The XACML PEP forwards authorization requests to a XACML policy decision point. It is aware of access roles and may also make determinations on the basis of a wide range of Fedora object and datastream properties. Policy sets may be customized for different part of the repository tree. For detail please see the XACML PEP. |
...
* or OAuth token with equivalent scope
Code Repository
The Fedora AuthN/AuthZ modules are in development here: