Documentation related to
We currently support a simple local authentication process. User accounts are stored in etcd with apr1 hashed passwords with associated per-namespace secrets. The apr1 format was used to support the NGINX ingress controller, which uses htpasswd files to enable basic authentication into services running in Kubernetes. The current authentication approach is undesirable for a variety of reasons, including double sign-in (custom login screen and basic auth) and lack of support for SSO. We've long discussed supporting Oauth, but didn't have a driving use case (until now). This documentation supersedes any other Oauth2 discussions (e.g., WSO2, etc).
We have three (or four) basic requirements for authentication/authorization going forward:
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. 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.
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.
Notes:
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).