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.

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

Document requirements towards compatibility of auth solutions between VEDA and MAAP #25

Open
1 task
j08lue opened this issue Jan 28, 2025 · 3 comments
Open
1 task
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@j08lue
Copy link

j08lue commented Jan 28, 2025

Context

At some point we'll need MAAP Auth and VEDA Auth to either align or be compatible to enable login to MAAP Hub (2i2c), and access to services the same way it works on VEDA (STAC transactions, etc...).

MAAP will have some additional services, like federation with ESA, and access to MAAP APIs like DPS job management.

Acceptance criteria

  • Clarify the needs for alignment between MAAP and VEDA and record them in the form of use cases
@j08lue j08lue added the documentation Improvements or additions to documentation label Jan 28, 2025
@wildintellect
Copy link

  • Registration of MAAP users
  • Login of MAAP users to MAAP Hub (migration from MAAP ADE to hub is a prime time to do this, aka Next 6 months)
  • Delegation of MAAP users to research groups, users may belong to multiple research groups. This authorization will determine which DPS queues and which shared buckets a user can use.
  • MAAP DPS API access (currently via a MAAP token injected into the session on boot)
  • MAAP user access to various STAC ingestion APIs to publish/edit STAC records.
  • MAAP federated access across NASA and ESA platforms. <- @smarru can probably explain the details of this better based on the meeting today with ESA.

@j08lue
Copy link
Author

j08lue commented Jan 30, 2025

These requirements for MAAP towards auth (in particular user groups, shared buckets, etc.) is what is developed under EOEPCA as the Workspace Building Block.

This building block provides services like provisioning, lifecycle management, quota, etc. of resources for groups of users, relying heavily on KeyCloak. It includes a UI for managing these resources.

I think their solution is pretty solid and we should really look into using it for VEDA.

The only caveat is that it builds on Kubernetes, like all EOEPCA building blocks - but so does our JupyterHub solution.

Would you be interested in exploring a match between what this solution provides and the requirements we see arising from MAAP, @wildintellect?

@wildintellect
Copy link

@j08lue yes, the only question is when do we involve 2i2c to see if they can simple deploy the building blocks as part of the hub?

cc: @zacdezgeo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants