...
User accesses www.workbench.nationaldataservice.org and selects "Sign in". They are prompted to enter their NCSA LDAP credentials. If they do not have an account, they can sign up via NCSA identity. When they sign in (similar to oauth), they will go through the approval workflow, if configured. The story is otherwise the same (single sign-on for Workbench services and containers, unable to access resources in another namespace/account).
Admin user
An admin user can login and access grafana/kibana/dashboards.
CLI user
User – particularly admin user – can login via CLI. Will likely require API token or spoofing oauth workflow via CLI.
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.
...