Standard authentication
User accesses www.workbench.nationaldataservice.org and selects "Sign-up". User enters registration information and submits. User is required to verify email address. Once verified, account goes through approval process (if enabled). Once approved, user can login to Workbench to start services. User starts Jupyter notebook. When user accesses Jupyter endpoint, if already authenticated they are not prompted to authenticate again. If they have not authenticated, user is prompted to authenticate using their Workbench credentials. If another user tries to access this user's Jupyter notebook, they are not permitted.
Oauth2 authentication (Globus auth)
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
- 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
