Skip to content

Allow pushing user-allocation membership to Keycloak#249

Open
QuanMPhm wants to merge 1 commit intonerc-project:mainfrom
QuanMPhm:ops_948/auth_kc
Open

Allow pushing user-allocation membership to Keycloak#249
QuanMPhm wants to merge 1 commit intonerc-project:mainfrom
QuanMPhm:ops_948/auth_kc

Conversation

@QuanMPhm
Copy link
Copy Markdown
Contributor

@QuanMPhm QuanMPhm commented Oct 3, 2025

Closes nerc-project/operations#948. More details in the commit message
There are still some questions I have below, so this is still a draft for now.

@QuanMPhm
Copy link
Copy Markdown
Contributor Author

QuanMPhm commented Oct 6, 2025

@knikolla Two more questions:

  1. Do we also want validate_allocations to add PIs to Keycloak groups for pre-existing allocations?
  2. When a PI adds a user to an Coldfront project or allocation, do those users also get added to a the project's Keycloak group?

@QuanMPhm
Copy link
Copy Markdown
Contributor Author

@knikolla I've addressed your comments except one. Also, do you have responses to these questions?

@knikolla
Copy link
Copy Markdown
Collaborator

@QuanMPhm please resolve conflicts. Are there any questions that I missed answering?

@QuanMPhm
Copy link
Copy Markdown
Contributor Author

@knikolla Just this one. I will resolve the conflicts while waiting for your answer

@knikolla
Copy link
Copy Markdown
Collaborator

@knikolla Just this one. I will resolve the conflicts while waiting for your answer

Responded.

@QuanMPhm QuanMPhm force-pushed the ops_948/auth_kc branch 2 times, most recently from a217f31 to 0358cb7 Compare March 20, 2026 20:28
@QuanMPhm QuanMPhm marked this pull request as ready for review March 20, 2026 20:41
Copy link
Copy Markdown
Collaborator

@knikolla knikolla left a comment

Choose a reason for hiding this comment

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

Did a quick first pass and provided some comments.

Also this needs to be possible configurable via a setting.

@knikolla
Copy link
Copy Markdown
Collaborator

@QuanMPhm Actually, another thought, do you think it would make sense to implement this in the Keycloak plugin? https://github.com/nerc-project/coldfront-plugin-keycloak

It could listen to signals in the same way that the cloud plugin listens to signals. It already has a keycloak client implemented.

And there is nothing in pushing users to a Keycloak group that is specific to either OpenShift or OpenStack.

@QuanMPhm
Copy link
Copy Markdown
Contributor Author

@knikolla I see that it does make sense to seperate the Keycloak functionality from the rest of the plugin. It makes sense to me. I forgot that repo existed. There would need to be some overhaul to add integration and unit tests to coldfront-plugin-keycloak. Is that fine?

@knikolla
Copy link
Copy Markdown
Collaborator

@knikolla I see that it does make sense to seperate the Keycloak functionality from the rest of the plugin. It makes sense to me. I forgot that repo existed. There would need to be some overhaul to add integration and unit tests to coldfront-plugin-keycloak. Is that fine?

For now let's keep it here (as not to frontload the work) and we can easily split it out later if needed. Perhaps try implementing it here via signals so as to keep it loosely coupled so that if we need to split it later it doesn't require a lot of uncoupling.

@QuanMPhm
Copy link
Copy Markdown
Contributor Author

QuanMPhm commented Apr 6, 2026

@knikolla @larsks I have a question about the Coldfront Keycloak PR. I know we previously decided to represent user-membership to an allocation by adding them to a Keycloak group with the same name as the ALLOCATION_PROJECT_ID . Would it make more sense for the group name to be the allocation's ID on Coldfront instead? This has a stronger guarantee of uniqueness, and we won't have to disambiguate for projects with the same name in different clusters. Developers or tools can correlate the allocation id to the on-cluster project id by using the Coldfront API.

@knikolla
Copy link
Copy Markdown
Collaborator

knikolla commented Apr 6, 2026

@knikolla @larsks I have a question about the Coldfront Keycloak PR. I know we previously decided to represent user-membership to an allocation by adding them to a Keycloak group with the same name as the ALLOCATION_PROJECT_ID . Would it make more sense for the group name to be the allocation's ID on Coldfront instead? This has a stronger guarantee of uniqueness, and we won't have to disambiguate for projects with the same name in different clusters. Developers or tools can correlate the allocation id to the on-cluster project id by using the Coldfront API.

See my comment here #249 (comment)

@QuanMPhm QuanMPhm force-pushed the ops_948/auth_kc branch 2 times, most recently from 96e371c to 97d7220 Compare April 7, 2026 18:58
@QuanMPhm QuanMPhm requested a review from knikolla April 7, 2026 19:06
@QuanMPhm
Copy link
Copy Markdown
Contributor Author

QuanMPhm commented Apr 7, 2026

@knikolla @larsks I have revised the PR and made the Keycloak integration a toggle-able feature. Calls to the Keycloak API is now triggered through signals. I have questions below that I think would be of interest to you both

Copy link
Copy Markdown
Collaborator

@knikolla knikolla left a comment

Choose a reason for hiding this comment

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

Quick first pass for direction feedback.

Copy link
Copy Markdown
Collaborator

@knikolla knikolla left a comment

Choose a reason for hiding this comment

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

Looking much better. Almost there.

A follow-up to this (after we merge the validate_allocations refactor) should investigate how to cleanly implement this in validate_allocations too.

CloudResourceAttribute(name=RESOURCE_PROJECT_DOMAIN),
CloudResourceAttribute(name=RESOURCE_ROLE),
CloudResourceAttribute(name=RESOURCE_QUOTA_RESOURCES),
CloudResourceAttribute(name=RESOURCE_KEYSTONE_GROUP_TEMPLATE),
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Keycloak :)

@knikolla
Copy link
Copy Markdown
Collaborator

knikolla commented Apr 7, 2026

Looking much better. Almost there.

A follow-up to this (after we merge the validate_allocations refactor) should investigate how to cleanly implement this in validate_allocations too.

Actually... I would make it a whole separate CLI command. validate_keycloak_groups.

A Keycloak admin client has been added
When `activate_allocation` is called, the user is added
to a Keycloak group named using a format string defined in the
allocation's resource attribute "Format String for Keystone Group Names"
If the user does not already exist in Keycloak, the case is ignored for now

Keycloak integration is optional, toggled by setting the env var "KEYCLOAK_BASE_URL"
Authentication to Keycloak is done via client credentials grant

When `deactivate_allocation` is called, the user is removed from the Keycloak group

New functional test added for Keycloak integration

A comment in `validate_allocations` has been updated to
reflect the more restrictive validation behavior, where users on cluster projects
will be removed if they are not part of the Coldfront allocation (rather
than if they are not registered on Coldfront at all).
@QuanMPhm
Copy link
Copy Markdown
Contributor Author

QuanMPhm commented Apr 8, 2026

@knikolla I've allowed the group name template string to accept any allocation attribute. Further documentation is in the docstring for the function _get_keycloak_group_name

@QuanMPhm QuanMPhm requested a review from knikolla April 8, 2026 14:38
@knikolla
Copy link
Copy Markdown
Collaborator

knikolla commented Apr 8, 2026

@naved001 would appreciate a pass from you.

Copy link
Copy Markdown
Collaborator

@knikolla knikolla left a comment

Choose a reason for hiding this comment

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

Had some more time to think about how to expose enabling/disable the feature.

attributes.RESOURCE_KEYCLOAK_GROUP_TEMPLATE
)
if group_name_template is None:
logger.warning(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I had some more time to think about this. Instead of logging a warning, log an info message here, this way the presence of the Keycloak Group Template Resource Attribute can act as a flag for enabling the feature for each specific Resource individually.

Therefore also switch the order so that the group template is parsed before you look up the user.

Keycloak enabled but no group name template specified for resource <>. Skipping addition to Keycloak group.

attributes.RESOURCE_KEYCLOAK_GROUP_TEMPLATE
)
if group_name_template is None:
logger.warning(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Same comment as from addition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Investigate centralizing authorization for NERC users in Keycloak

2 participants