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

Added token revocation functionality to Managed Identity #7422

Open
wants to merge 15 commits into
base: dev
Choose a base branch
from

Conversation

Robbie-Microsoft
Copy link
Collaborator

@Robbie-Microsoft Robbie-Microsoft commented Nov 15, 2024

If claims are present, the cache will already be bypassed. Now, additionally, bypass_cache=true will be included in the token request, as a query parameter, which indicates to ESTS that it should get a new token.

Client Capabilities can now, optionally, be sent to ESTS as a non-empty string query parameter in the form of xms_cc=client-capabilities-string-separated-by-commas.

Client Capabilities can be set in the Managed Identity configuration object, which is consistent with non-Managed Identity configurations.

@github-actions github-actions bot added the msal-node Related to msal-node package label Nov 15, 2024
@github-actions github-actions bot added the documentation Related to documentation. label Nov 15, 2024
@Robbie-Microsoft Robbie-Microsoft marked this pull request as ready for review November 15, 2024 22:27
@@ -549,13 +550,136 @@ describe("Acquires a token successfully via an IMDS Managed Identity", () => {
);
});

test("ignores a cached token when claims are provided", async () => {
test('checks if a token was cached or not and if was "bypass_cache=true" was sent to ESTS depending on whether or not claims are provided, and ensures "xms=client-capabilites-string" was sent to ESTS when client capabilities are provided via the Managed Identity Request Parameters', async () => {

Choose a reason for hiding this comment

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

I think you should also include tests when claims are passed, and client capabilities are not and when client capabilities are passed, and claims are not.

Copy link
Member

@bgavrilMS bgavrilMS Nov 26, 2024

Choose a reason for hiding this comment

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

I think some are covered, but the tests are somewhat difficult to read.

There are 3 dimensions for this test, each with 2 possible values. So a total of 2^3 = 8 combos.

CP1: {sent, not_sent}
Claims: {sent, not_sent}
Token_in_cache? { yes, no}

Copy link

@neha-bhargava neha-bhargava left a comment

Choose a reason for hiding this comment

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

Recommend adding more unit tests for the combination of presence of client capabilities and claims. Also were you able to test all the scenarios manually?

@gladjohn
Copy link

gladjohn commented Nov 25, 2024

@Robbie-Microsoft MSI v1 token revocation is supported only on MSI endpoints versioned 2024-09-30 .

@@ -55,6 +55,7 @@ import {
} from "../../../src";
Copy link
Member

Choose a reason for hiding this comment

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

The tests aren't related to IMDS? Is this the right location for them?

Copy link
Member

@bgavrilMS bgavrilMS left a comment

Choose a reason for hiding this comment

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

ClientCapabilities is an app level setting. Isn't it the case for ConfidentialClientApplication?

@Robbie-Microsoft
Copy link
Collaborator Author

ClientCapabilities is an app level setting. Isn't it the case for ConfidentialClientApplication?

Yes. Fixed in this PR now.

@Robbie-Microsoft
Copy link
Collaborator Author

Robbie-Microsoft commented Nov 27, 2024

Bump every source's version?

We should bump the source's version to the one that supports MSI V1 CAE. But there are no Azure Resource that still supports this in GA, so we should bump the version for just this PR, mark it as do not merge and do a private a release from the PR branch so MSI team/MSI RPs can test it. When all Azure MI Resources support the API CAE version then we can merge and GA.

Give the dev an option to choose their version?

No, we should not.

Is there supposed to be a fallback action if the minimum version is not met?

MI Teams needs to guarantee that the version is updated across the board / azure resources, we will then test add e2e and then release/GA. For now, this is just an internal preview. So do not merge this PR.

ARC_API_VERSION;
request.queryParameters[RESOURCE_BODY_OR_QUERY_PARAMETER_NAME] =
request.queryParameters[ManagedIdentityQueryParameters.API_VERSION] =
MSI_V1_MIN_VERSION;
Copy link

Choose a reason for hiding this comment

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

Service Fabric will be the only resource that supports Token Revocation for now. For the private preview let's only focus on Service Fabric and not change the api-version for other Azure resources

Copy link
Member

@bgavrilMS bgavrilMS left a comment

Choose a reason for hiding this comment

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

I am not convinced that this is the final, approved protocol. We should not have a PR without an E2E validation (even manual).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do not merge documentation Related to documentation. msal-node Related to msal-node package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants