...
| Info | ||
|---|---|---|
| ||
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. |
OAuth 2.0
...
User Authentication
This feature allows a user to sign-in via a third-party service, such as Google, Yahoo or Facebook. The result of the OAuth 2.0 authentication flow is a username and access to whatever user account details are within the authorized scope, such as email address. Fedora is then free to use these user details to create a local user account or assign privileges as required for Fedora authorization. (All that this work flow provides is user authentication.)
OAuth Roles
- Client Application - Fedora
- Authorization Service - Google, etc..
- Resource Server - Fedora
OAuth 2.
...
0 Applications Authorization
From the OAuth 1.0 specification:
...
Applications can be authenticated by means of token credentials generated through the OAuth 2.0 framework.Subject Subject to the practical limitations explored below, Fedora will be designed such that authorization happens within the OAuth workflow.While While OAuth is supported and encouraged, applications can still authenticate via container-level "user authentication". OAuth support is not required of all Fedora client applications.
OAuth Roles
- Client Application - custom front end, fedora proxy, or message-driven service
- Authorization Service - Fedora
- Resource Server - Fedora
Possible Limitations
- 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.
- Similarly, how much access can a single OAuth token cover? Can they be patched or modified after authorization to cover more cases?
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?
...
OAuth Token Scopes
| scope | authorizer | definition |
|---|---|---|
| forward credentials | fedoraAdmin role | ability to forward end-user credentials in headers |
| fedora administrator | fedoraAdmin role | ability to act in the fedoraAdmin role |
| * on behalf of X | fedoraUser X | ability to forward end-user X user principal |
| read only | both | may only read data |
| until time T | both | authorizes for a limited time T |
* 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 operations subject to the 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 authorized.
- 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.
Forwarding Security Credentials
...