Skip to content

Conversation

@adityadani
Copy link
Contributor

What this PR does / why we need it:

  • The auth interceptor will choose an authenticator based on the issuer and configured clientID combination.
  • From the token the clientID is checked from the audience field of the claim.
  • Since audience can contain more than just the clientID, the multi authenticator does a "Contains" check for the configured clientID and the audience field.

Which issue(s) this PR fixes (optional)
Closes #

Special notes for your reviewer:

- The auth interceptor will choose an authenticator based on the issuer and configured clientID combination.
- From the token the clientID is checked from the audience field of the claim.
- Since audience can contain more than just the clientID, the multi authenticator does a "Contains" check
  for the configured clientID and the audience field.

Signed-off-by: Aditya Dani <[email protected]>

type IssuerWithClientID struct {
Issuer string // Issuer of the token.
ClientID string // ClientID of the token, can be empty.
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe add a comment to indicate what it means to have an empty ClientID. This was not obvious to me.

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 have removed the comment and added an explicit check to fail if clientID is found to be empty. This behavior is clearer as compared to allowing empty clientIDs. Another thought is this multi authenticator really makes sense only for OIDC authenticators where we definitely need a clientID to verify the token. May be we could rename this to OIDCMultiAuthenticatorsWithClientID or so

@adityadani adityadani force-pushed the multi-clientID-support branch 2 times, most recently from d1c16e7 to d82a208 Compare March 1, 2023 01:19
@adityadani adityadani requested a review from pureneelesh March 1, 2023 01:22
@adityadani adityadani force-pushed the multi-clientID-support branch from d82a208 to 8d5149b Compare March 1, 2023 01:23
Signed-off-by: Aditya Dani <[email protected]>
@adityadani adityadani force-pushed the multi-clientID-support branch 2 times, most recently from 79c1c8d to f9abb7f Compare March 1, 2023 20:48
assert.Equal(t, "my-name", authenticateClaims.Name)
assert.Equal(t, []string{"tester"}, authenticateClaims.Roles)

rawToken2, err := Token(&Claims{
Copy link
Contributor

Choose a reason for hiding this comment

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

rawToken2 looks the same as rawToken1. What are we testing here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The signature key is different my-secret-2. Basically trying to test both authenticators from the same issuer are being used.

Copy link
Contributor

Choose a reason for hiding this comment

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

so, should rawToken1 use "my-secret-1" on line 106? It says "my-secret-2".

- Create a list of authenticators for each issuer.
  Remove the requirement for providing a clientID.
- This allows adding self signed authenticators to the same multi authenticators interface.

Signed-off-by: Aditya Dani <[email protected]>
Signed-off-by: Aditya Dani <[email protected]>
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