This repository has been archived by the owner on Dec 7, 2023. It is now read-only.
Improve upon the "all-or-nothing" authentication implementation #39
Comments
|
The thoughts described in #21 (comment) are a pre-requisite to implementing this feature. |
JeanMertz
added a commit
that referenced
this issue
Jul 23, 2019
This commit builds on top of 411e8e2 to provide a more layered authentication/authorization model, based on the thoughts described in #39. The goal of this commit is to transform the "all-or-nothing" authentication model into one that allows for fine-grained access control _and_ allow unauthenticated access to the system. This creates a more friendly environment for people within an organisation using Automaat for the first time. Instead of shoving them a login dialog in their face on their first visit, the server allows access to all GraphQL queries, to support a client that can show the full capabilities of API. Instead, a new privileges-based system is implemented that restricts GraphQL mutation access based on a set of matching rules where each mutation requires a specific privilege to be granted to a session. For tasks, each task can define one or more labels, for which at least one must match a session's privileges in order to run that task. If a task defines no labels, the task can be run by unauthenticated sessions. This allows for patterns where simple side-effect-free tasks can be used by anyone in the organisation to retrieve vital information via Automaat, without having to authenticate.
JeanMertz
added a commit
that referenced
this issue
Jul 23, 2019
This commit builds on top of the new privileged-based layered API access introduced in abd8f76. The commit reverts part of the changes introduced in 5552179 and builds upon the parts that remain. It is now (again) possible to access the client without being authenticated. The client works as it did before, all data is accessible and visible. However, when you open a task, it will now show you either the original "run" button, or – depending on your access level – a button informing you that you need to authenticate to run the task, or if you are already authenticated but lack sufficient privileges, it will inform you that you cannot run said task. The "Authentication Required" button can be clicked to show a more friendly inline login field, that doesn't cover the entire screen, and can be ignored if you are not interested in authenticating. All in all, this provides a _much_ friendlier user experience, while also allowing for more fine-grained access control. This closes #19, #21, and #39.
|
This has been implemented in bf9ffe4.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This will build upon #19.
One of the things I dislike about the current authentication model is that it's not well suited for the purpose it's supposed to fill.
Specifically, the authentication implementation is not meant for outside access restriction, but is purely meant to add some more control and auditing to internal Automaat access within your company (and to eventually segregate who can run what task, with #21).
With the current authentication model, if you visit your company's Automaat instance, you're greeted with this giant display of "NO ACCESS", and you have to jump through hoops to even be allowed to peek behind the curtain to see what this tool could offer you in terms of tasks built by your colleagues useful to your daily work:
I'd much rather see a more fine-grained implementation that allows you to browse the available tasks (and potentially use tasks that can be run without authentication), and then when the time comes that you want to run a task that requires certain access rights, you are asked to provide the correct credentials.
This requires some fine-tuning of the authentication implementation, and also requires a more central role of authentication and access rights throughout the web client code-base.
Here are some thoughts:
The server API no longer implements a blanket "error unless authenticated" approach, but instead:
The client allows viewing/opening tasks
If a task requires authentication to run, and you are not authenticated, the usual "Run Task" button changes colour, and let's you know you need to authenticate (clicking the button allows you to log in), something like this:
If you are authenticated, but lack the proper privileges, this is also explained via the button (in this case, clicking the button doesn't work, as you need to ask someone to give you the correct privileges to make things work):
Other than this, the client will also need to take the availability of session state into account when implementing Add a "favourites" tasks list #9, Add "one-click" tasks #10 and the likes. Meaning, when authenticated, these functionalities should be available, but when not authenticated, they are either hidden or provide some reduced functionality (tbd.).
The text was updated successfully, but these errors were encountered: