Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Review and refine ADR about Keycloak middleware #87

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Review and refine ADR about Keycloak middleware #87

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
522dfe4
Neutralize and expand decision drivers
j08lue Aug 19, 2024
dfa0d5d
Add decision driver about GUI
j08lue Aug 19, 2024
25cc4b4
Update pros and cons related to GUI
j08lue Aug 19, 2024
59d7012
Change from requirements to criteria
j08lue Aug 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions docs/architecture-decision-records/layering-on-keycloak.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,9 +38,12 @@ VEDA Auth Central deploys and manages out of the box open source Keycloack for V


## Drivers
- **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).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alukach has raised this already in #85 (comment). It would be very useful to get more clarity about these!

- **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
Comment on lines +41 to +46
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are the most significant changes to review.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Collaborator Author

@j08lue j08lue Aug 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@j08lue did you mean the google doc or #85 (reply in thread)?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Considered Options:

Expand All @@ -49,6 +52,7 @@ VEDA Auth Central deploys and manages out of the box open source Keycloack for V
- Simple to implement with minimal development effort.
- Utilizes Keycloak’s built-in features and administration tools.
- Lower initial setup cost.
- Comes with an admin GUI.
- **Cons:**
- Lacks support for application-specific authorization, complex user onboarding, and automated group management.
- Cannot support advanced use cases like scope inheritance or application-based user subscriptions.
Expand All @@ -67,9 +71,12 @@ VEDA Auth Central deploys and manages out of the box open source Keycloack for V
- Provides the flexibility to implement specific business logic, including fine-grained authorization and user management.
- Allows Keycloak to be upgraded and maintained independently of the custom logic.
- Supports the scalability and customization needs of Veda Auth Central without overly complicating the core IAM solution.
- 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.
- **Cons:**
- Additional development effort required to create and maintain the custom layer.
- Additional effort required to develop and maintain the custom layer and its documentation.
- Potential for increased complexity in managing the interaction between Keycloak and the custom layer.
- Risk of requiring solution-specific logic on the application side.
- Requires development of a custom administation GUI.

## Decision Outcome

Expand Down