Define how the authorization in the UI server will work with other components

[kinow]

JupyterHub has authentication, and also a thin layer of authorization in its reverse proxy. But the Cylc UI server will need to redefine parts of its authentication.

This issue is to record discussions on authorization for the UI server, which will interface with JupyterHub and probably be used by Cylc Web as a bridge to communicate with cylc and JupyterHub.

See related discussion in cylc/cylc: https://github.com/cylc/cylc/issues/1901

See related discussion in cylc/web: https://github.com/cylc/cylc-web/issues/60

[kinow]

Discussion on Discourse with good user requirements: https://cylc.discourse.group/t/the-role-of-the-ui-server-in-production-from-a-user-and-permissions-point-of-view-cylc8/55

[kinow]

While testing the LDAP Authenticator today (#51), I started looking for the groups. I tried to understand the concept of groups in JupyterHub, related to Authenticators.

An authenticator and a spawner may use the system groups to authenticate the user, or when forking a spawner process to use the user/group IDs.

But after that, the REST API endpoint /groups and the SQLite database table groups, both seem to be more related to JupyterHub, and not to the system groups.

So even though my Linux user has over 5 groups (kinow, cdrom, adm, docker, etc), after my first log in, the groups table is empty.

I can use the REST API to add groups to my existing user, but these groups won't be really related to my OS users.

This may be useful in the future in case users want to have authorization based on their existing groups in Active Directory, FreeIPA, etc. I couldn't find an existing way to sync groups between OS and JupyterHub; though it should be doable either by extending the authenticator, or by using a service.

[kinow]

Kubernetes has a good model for RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/. Airflow appears to have used it as reference too (found the link in their docs).

Jenkins too, and it's configurable (using multiple strategies, like their matrix authorization strategy: https://plugins.jenkins.io/matrix-auth/)

I think JupyterHub RBAC might look similar to the Kubernetes model. In which case, we could use their authorization too.

(commenting here because the issue I found for Cylc Flow appears to be more for the CLI https://github.com/cylc/cylc-flow/issues/2729, and whatever is defined here would drive the UI too I think)

[hjoliver]

Comments on authorization here:

• https://github.com/cylc/cylc-uiserver/issues/27#issuecomment-668478159
• https://github.com/cylc/cylc-uiserver/issues/27#issuecomment-668478637

[hjoliver]

Authorization, from Feb 2020 workshop notes:

• need site and user config
• user can ramp up authorization levels as far as the site allows
• groups:
  • (1) locally (site and user) defined lists
  • (2) access to Unix OS groups
  • (3) LDAP groups? (Does the Hub authentication plugin return this info? Probably not?)
    • or query getent()?
    • (JR) OS groups would do, as we link OS and LDAP groups
      • do (1) and (2) initially, (3) etc. after 8.0
  • auth config file needs to be .cylc format

• authorization config files:

Plus:

• authorization methods and config, as a UIS sub-service

[jarich]

Further to this, and harking back to https://cylc.discourse.group/t/the-role-of-the-ui-server-in-production-from-a-user-and-permissions-point-of-view-cylc8/55/8 in some ways, our usage of Cylc provides read-only views into production versus read-execute, and read-write-execute views.

I understand that the Jupyter UI Servers expect the person logging in to have shell accounts to the machine that the UI Server is running on; and of course it would make sense for the standard use-case for the Cylc 8 UI Servers to have shell accounts too (for their own workflows). However, in the case where we want to provide read-only views into production, we almost certainly do not want to provide those users with shell accounts.

It would be useful if there was a capability for having shell=false for most/all users who log in, while being able to see the list of other users' workflows they are authorized to see. That is, my lack of shell or workflows, should not mean I can't see the workflows I have authorization to see.

[hjoliver]

I understand that the Jupyter UI Servers expect the person logging in to have shell accounts to the machine that the UI Server is running on ...

No, not necessarily. The (privileged) hub has to be able to start a UI Server as the target user (i.e. the owner of the workflows), not the authenticated user, if there is not already one running there. The UIS will then authorize restricted access to its schedulers, according to what rights the owner has granted the authenticated user.

[oliver-sanders]

removing the question label as we have an accepted cylc-admin proposal - https://github.com/cylc/cylc-admin/blob/master/docs/proposal-multi-user-approach.md#configuration