Review and refine ADR about Keycloak middleware #87
Conversation
| - **Supports Complex Authorization Needs**: Support application-based user subscriptions, scope inheritance, and detailed access control for multiple environments (dev, staging, production). | ||
| - **Simple Administration**: How easy it is for administrators such as science program leads to manage users or groups on their own | ||
| - **Graphical User Interface**: Ease of providing a graphical user interface for user and group administration | ||
| - **Community friendly**: How well the solution fits into VEDA as an ecosystem of community-maintained open source platform components | ||
| - **Generic integration**: Whether the solution offers generic integration patterns, such that applications can reuse logic for other publicly available providers like Auth0 | ||
| - **Well documented**: Quality and completeness of documentation, important to ensure good uptake by applications and other instances of the platform |
There was a problem hiding this comment.
These are the most significant changes to review.
There was a problem hiding this comment.
@j08lue can we explicitly add "support for Device Authentication Flow / Grant" to the document?
I imagine this would be the recommended way for users to authenticate and get elevated scopes from remote environments like JupyterHub.
There was a problem hiding this comment.
Yes, let us do that.
I think this document should not turn into a requirements list for the auth solution, though - that list should live elsewhere - right now that is what is happening in the use cases doc, I guess? WDYT, @DImuthuUpe and @smarru?
There was a problem hiding this comment.
@batpad Typically device auth flow is being used for tools installed on devices (IDEs, Collaborative tools). For web apps like JupyterHub it is better to be done through standard redirects. If you have some references for this recommendation, please let us know.
There was a problem hiding this comment.
@j08lue did you mean the google doc or #85 (reply in thread)?
There was a problem hiding this comment.
@DImuthuUpe thanks for the comment, and I probably should have explained better.
Let me know if it's useful to break this out into a separate ticket, as the discussion around how users authenticate from within JupyterHub to access other services is likely a conversation that involves more people involved, and I want to do that at the appropriate place.
Maybe for this document the high level requirement is something like "Allow for users on remote machines to authenticate in an easy and secure way".
You are very correct that for a regular webapp, one would use OAuth with standard redirects, and this is what we would do to login to JupyterHub itself. When a user is accessing a JupyterHub instance through their browser, it's very similar to an ssh session, or a session to a remote machine, just happening through the browser. So a use-case here would be:
A user, using a remote shell in the Jupyter instance, needs to authenticate to a VEDA app, for example the STAC backend. We likely have two options here:
- User initiates the Device Auth Flow process, gets a URL to login to, log in another tab, and have themselves "logged in" on the remote shell.
- We create some extension to the Jupyter UI which follows the OAuth redirect flow, and manages injecting the token into the user's remote shell or notebook environment.
I am definitely not the expert on this, and there maybe things I might be missing. From conversations with @yuvipanda and @alukach, it seemed that Device Auth Flow would be a good way to support authentication for people who needed to run scripts on remote machines, either over things like ssh or via JupyterHub.
If it seems like it might be hard to support Device Auth Flow, or if this requires further discussion, am happy to make a ticket specifically for this to get into details a bit. Thanks again for the response here!
There was a problem hiding this comment.
This is very helpful. Thanks @batpad. Now I understand your thought process. Regarding the device auth flow, it can be enabled. We might have to move this discussion to a different ticket to talk about that as that decision depends on the usecase. But we can assume the auth central will enable all the auth flows described in Oauth2 spec.
| - **Supports Complex Authorization Needs**: The custom layer addresses specific authorization needs that are not natively supported by Keycloak, such as application-based user subscriptions, scope inheritance, and detailed access control for multiple environments (dev, staging, production). | ||
| - **Simplifies Administration and Reduces Misconfiguration Risk**: By introducing application-specific entities and reusable templates, the custom layer simplifies the management of access policies and reduces the risk of misconfiguration that could arise from directly managing these controls within Keycloak. | ||
| - **Improves User Management**: The user enrichment module centralizes and automates user onboarding and group management, providing a clearer and more organized structure for user roles and permissions across all VEDA applications. | ||
| - **Supports Complex Authorization Needs**: Support application-based user subscriptions, scope inheritance, and detailed access control for multiple environments (dev, staging, production). |
There was a problem hiding this comment.
What does 'application-based user subscriptions' mean? It doesn't seem to be a term that's commonly used in the authentication / authorization community, I can't find a definition of that in the NASA-IMPACT github org, in this repo, in the Apache custos repo, any of the google docs that has been shared with me (at least according to google drive, but that's not exhaustive) or in slack. If it's an important driver, I want to understand what it means and which application needs it.
There was a problem hiding this comment.
Similar question for 'scope inheritance', and how it differs from 'child groups' that keycloak offers.
Groups are hierarchical. A group can have multiple subgroups but a group can have only one parent. Subgroups inherit the attributes and role mappings from their parent. Users inherit the attributes and role mappings from their parent as well.
There was a problem hiding this comment.
@alukach has raised this already in #85 (comment). It would be very useful to get more clarity about these!
We would like to document the rationale for creating a layer on top of Keycloak that acts as a reverse proxy and implements application-based logic and management functionality.
This PR is to review the previously submitted ADR and give the team a chance to comment or request changes.
@alukach @yuvipanda @batpad @smohiudd @anayeaye
Tasks