...
User accesses www.workbench.nationaldataservice.org and selects "Sign-in" using Oauth/Globus. If user is not authenticated, user is redirected via Oauth. Once authenticated, if user has no account, an account record is created. No email verification is required. If approval is enabled, account goes though approval workflow. Otherwise, story is the same as above.
Considerations
Possible implementation
- Create custom authorization component (similar to cauth) that can be used as first-level authorization. This component would control whether to use the standard workbench authentication or oauth and know how to handle the Workbench auth token. If a token exists and is valid for the user/namespace, the user would be authorized to access the requested resource. If the token doesn't exist, the user would be routed through the authentication flow (i.e., /oauth2)
- Under this approach the "cauth" module would proxy all requests to the oauth2_proxy and need to be able to handle the /oauth2 endpoint calls.
- Create an account/token creation component that is downstream from the oauth2_proxy. This would receive the oauth2 headers (user, email, token) and be responsible for account creation/update and creating/setting the token cookie.
- This may be the same as the cauth component, but would be "chained" as an upstream to the oauth2_proxy.
Notes about oauth2_proxy
- There is a working example of oauth2_proxy working with nginx ILB here: https://github.com/craig-willis/oauth2-k8s
- Oauth2 information (token, username, email, etc) are only available to configured oauth2_proxy upstreams.
- The upstream response codes are ignored (e.g., 401/403), so this cannot be used for authorization
- The upstream can set a cookie (i.e., token used by other applications)
- The upstream must have it's own path (i.e., something other than the already-taken start, sign_in, auth endpoints).
- Oauth2 information is only available to services that are "upstream" from the Oauth2 proxy. The upstream response code appears to be ignored (e.g., 401/403). The upstream can, however, set a cookie. This suggests that we will need our own authorization component in the auth pipeline.
- With the current configuration, nginx uses the oauth2_proxy as an "auth_request" provider. We will likely want to add our own authorization component
- nginx > oauth2_proxy > account creation component/token generator
- nginx > cauth
- nginx > authorization component > oauth2_proxy > account creation component/token generator
- Under this flow, nginx will pass the request to the authorization component (cauth?) which understands the token.
- If a token exists and is valid for the user's namespace, the user is authorized If a token does not exist, the request moves through the oauth2 workflow (login, create token and account record, if necessary)
Overview
| Gliffy Diagram | ||
|---|---|---|
|
...