Skip to content

Conversation

adutra
Copy link
Contributor

@adutra adutra commented Aug 19, 2025

This change removes the requirement for Polaris principals to have a numeric identifier, by removing the only sites where such an identifier was required:

  • In the Resolver. Instead of lookups by id, the Resolver now performs lookups by principal name.
  • In PolarisAdminService. Instead of comparing entity ids, the code now compares the principal name against the entity name and type.

Note: the lookup in the Resolver is still necessary, because the Resolver also needs to fetch the grant records.

This change removes the requirement for Polaris principals to have a numeric identifier, by removing the only sites where such an identifier was required:

- In the `Resolver`. Instead, the `Resolver` now performs a lookup by principal name.
- In  `PolarisAdminService`. Instead, the code now compares the principal name against the entity name.

Note: the lookup in the `Resolver` is still necessary, because the `Resolver` also needs to fetch the grant records.
@adutra adutra force-pushed the auth-refactor-remove-principal-id branch from 7d3bf24 to 696afc3 Compare August 19, 2025 12:02
@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Aug 19, 2025
Copy link
Contributor

@dimas-b dimas-b left a comment

Choose a reason for hiding this comment

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

LGTM 👍

*/
private static boolean isSelfOperation(PolarisAuthorizableOperation op) {
return op.equals(PolarisAuthorizableOperation.ROTATE_CREDENTIALS)
|| op.equals(PolarisAuthorizableOperation.RESET_CREDENTIALS);
Copy link
Contributor

Choose a reason for hiding this comment

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

side note: RESET_CREDENTIALS is no going to be a "self" operation after #2197

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My understanding of #2197 is that the root user will be able to reset credentials of another user, but it won't remove the possibility for any user to reset their own credentials. So in a way it it still a "self" operation. Am I missing something?

Copy link
Contributor

Choose a reason for hiding this comment

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

IIRC, in current main the RESET_CREDENTIALS operation is "dead code" (but will be restored to active service by #2197).

Copy link
Contributor

Choose a reason for hiding this comment

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

I do not think a self-reset of credentials will be allowed, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, should I remove this check? IMO any changes here should be made by #2197 itself, but I don't mind proactively changing this bit in this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see the change has been made in #2197: only ROTATE_CREDENTIALS remains a "self-operation".

Copy link
Contributor

@dimas-b dimas-b Aug 22, 2025

Choose a reason for hiding this comment

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

I agree that this change should be made under #2197. I commented here only as a "heads up" hoping to clarify potential merge conflicts. Sorry, if I caused confusion 😅

@dimas-b dimas-b requested a review from dennishuo August 19, 2025 22:58
@adutra
Copy link
Contributor Author

adutra commented Aug 22, 2025

@dennishuo @collado-mike PTAL.

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.

3 participants