Authentication, and fine-grained authorization

[hjoliver]

Supersedes #1475 and #1520.
Choose and use existing web-based authentication technologies; depends on #1872.

See also #526.

(EDIT Bruno): see also discussion in cylc-web and in cylc-jupyterhub

[matthewrmshin]

Some ideas discussed:

1. We'll need to extend the current set of privilege levels - the grains should be individual API methods, although it should still be able to group them together into coarser categories.
2. The easiest and most portable way to support authentication is via a private-public key pair. We can have a simple command for a user to create a private-public key pair in a standard location. The user can then send requests to a suite requesting authorisation for certain actions using the public key. The suite owner can then decide to authorise each requested action for the user.

[hjoliver]

It seems we need to be able to work with standard site "identity management" systems. Primary use case: production suites under role accounts that need to handle restricted access from multiple operators, and unrestricted access from expert support people. Hopefully a generic interface in cylc, with simple plugins for external interaction. Defaulting to something very simple that does not complicate life for "normal" users. More to come on this...

[hjoliver]

Current thinking on this:

In the web GUI era we need a "reverse proxy server" as a gateway between the in-browser GUI and the suite server programs. Authentication can probably (hopefully?) be done at the proxy server - rather than at the suites as now - by calling out (via some off-the-shelf plugin, perhaps) to site identity management. Then an SSL Client Certificate held by the proxy server will allow suite server programs to simply trust all communications from the proxy.

[hjoliver]

(Note comment above is now outdated).

Now: call-out to authenticate at the Hub (co-opting JupyterHub for this). Then Hub-UIServer trust is by token, not SSL Client Cert.

[matthewrmshin]

Then Hub-UIServer trust is by token, not SSL Client Cert.

Definitely better this way.

[hjoliver]

This can be closed as superseded, as soon as I find the superseding issues (which may still be coming into existence).

[hjoliver]

In Cylc 8 authorization will be handled by the new UI Server component. Closing this as superseded by cylc/cylc-uiserver#10