[Identity] Ensuring the claims get sent through the getToken requests. by sadasant · Pull Request #18445 · Azure/azure-sdk-for-js

sadasant · 2021-10-29T18:06:01Z

By this point, core is ready to handle challenges. Identity should have been ready a while ago, but as I tested this feature, I realized I had forgotten to ensure the claims would go through the getToken requests. I believe this happened as we decided to drop the claims from the GetTokenOption. The reason why we dropped claims were, if I remember correctly, that claims could be either strings or objects with potentially arbitrary properties, and that they were only used internally and not expected to be used by customers.

Anyway, this PR intends to do something rather narrow:

Ensure claims are sent through correctly.
See what other properties we can send through that could have been missed.
Add two recorded tests for the challenge flow.

There are some questions I have remaining, regarding the recorder. I’ll route those questions outside of this PR. I’ll potentially make issues.

If you’re wondering why am I not using ARM endpoints for this test, the reason is that I wasn’t able to revoke the ARM session when I tested this. I tried many times. The Identity SDK crew is investigating that outside of this PR. Once that is resolved, I will add recorded tests for the ARM endpoints.

I may open some issues based on this PR, but give me some time to discuss our findings with the team.

…Policy

Co-authored-by: Jeff Fisher <xirzec@xirzec.com>

…Policy

sadasant · 2021-10-29T18:06:18Z

sdk/identity/identity/src/msal/credentials.ts

+  /**
+   * Claims received from challenges.
+   */
+  claims?: string;


This is an internal type.

sadasant · 2021-10-29T18:08:03Z

sdk/identity/identity/src/msal/nodeFlows/nodeCommon.ts

    });

-    let clientCapabilities: string[] = ["CP1"];
+    let clientCapabilities: string[] = ["cp1"];


If one goes to the service documentation, this value appears in lowercase: https://docs.microsoft.com/azure/active-directory/develop/claims-challenge

This change has no effect other than helping me have a more 1:1 comparison between our recordings and our docs.

… platforms

witemple-msft

Looks good to me. Checking my notes: this is part of the internal token options, but not the public GetTokenOptions, so this is meant to be used for challenges, but a user who is using identity will not have the option to pass in claims?

sdk/identity/identity/test/msalTestUtils.ts

sadasant · 2021-11-02T20:37:56Z

@witemple-msft (thank you)

I believe we deferred the decision of exposing the “claims” to end users. Claims can be either a base64 string or a JSON object, but the properties of that JSON objects are not well defined. Perhaps they will be in the future.

Better comment regarding dotenv.config

sdk/identity/identity/src/msal/nodeFlows/msalClientCertificate.ts

chlowell · 2021-11-03T00:07:51Z

sdk/identity/identity/test/public/node/caeARM.spec.ts

+      "Waiting for the revocation of the token. Retrying in 30 seconds. Retry number",
+      ++count
+    );
+    await delay(30000);


I think it's reasonable to give up after 8 minutes

This only gets executed on record mode. On playback mode this shrinks to 0. I’m only running this in playback mode on CI, so it won’t wait

chlowell · 2021-11-03T00:12:16Z

sdk/identity/identity/test/public/node/caeARM.spec.ts

+    // Important:
+    // IN PLAYBACK MODE...
+    // Verifying that the first access token and the final one are different will not work consistently in this test.
+    // The recorder strips out the access tokens from the responses on the recordings.


My solution in Python was to record hashes of the access tokens. That way the values are unique and no longer secret.

Our recorder in JS strips the access token, but the service sometimes answers with different expiration dates. I could add some boilerplate code to fix the resulting access tokens to different values, but it will get really cumbersome given that the recorder doesn’t play well with other mocking tools. For unit-tests, we already have unit tests in core-client and core-rest-pipeline about the underlying code used here.

…ing them on the recordings

sadasant · 2021-11-04T18:28:44Z

(well, that didn’t work)

check-enforcer · 2021-11-04T18:57:01Z

This pull request is protected by Check Enforcer.

What is Check Enforcer?

Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass.

Why am I getting this message?

You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged.

What should I do now?

If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows:
/check-enforcer evaluate
Typically evaulation only takes a few seconds. If you know that your pull request is not covered by a pipeline and this is expected you can override Check Enforcer using the following command:
/check-enforcer override
Note that using the override command triggers alerts so that follow-up investigations can occur (PRs still need to be approved as normal).

What if I am onboarding a new service?

Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment:
/azp run prepare-pipelines
This will run a pipeline that analyzes the source tree and creates the pipelines necessary to build and validate your pull request. Once the pipeline has been created you can trigger the pipeline using the following comment:
/azp run js - [service] - ci

…y matters

sadasant · 2021-11-04T20:12:17Z

I’ll merge this as soon as CI agrees with me.

Azure#18445) This PR: - Ensures claims are sent through correctly. - Sees what other properties we can send through that could have been missed. - Adds two recorded tests for the challenge flow. I’m not using ARM endpoints for this test since I wasn’t able to revoke the ARM session when I tested this. I tried many times. The Identity SDK crew is investigating that outside of this PR.

sadasant and others added 22 commits August 27, 2021 20:20

[core-rest-pipeline] armChallengeAuthenticationPolicy

dce7c17

no policy, just the callbacks on core-client WIP

90808dc

exporting just one of the challenge callbacks

955ec78

testing the core-client authorizeRequestOnClaimChallenge

10bcbd8

Merge remote-tracking branch 'Azure/main' into core-rest-pipeline/CAE…

a678671

…Policy

unnecessary change undone

4b36f5a

better changelog and code updates to the auth challenge

c8936eb

tests on the core-client

bcce127

no more recursive dependencies

e43f1b3

fixed browser tests

72e8ed7

Node 10 fix

6d42185

Update sdk/core/core-client/src/base64.browser.ts

4eab71d

Co-authored-by: Jeff Fisher <xirzec@xirzec.com>

feedback from Jeff and formatting

346b812

escape wasnt needed

4635468

decodeStringToString, feedback from Jeff

c99666b

Merge remote-tracking branch 'Azure/main' into core-rest-pipeline/CAE…

912ccd6

…Policy

CAE recorded test

a9dafa4

[Identity] Tested the DeviceCodeCredential with the CAE challenges

7b0be5d

Passing claims through. Other small fixes

2f54471

Merge remote-tracking branch 'Azure/main' into identity/CAEImprovements

a9632f7

CHANGELOG entry

b0d8c37

username password test

79a8a76

sadasant requested review from HarshaNalluru, KarishmaGhiya, chlowell, g2vinay and schaabs October 29, 2021 18:06

sadasant self-assigned this Oct 29, 2021

sadasant requested a review from witemple-msft as a code owner October 29, 2021 18:06

ghost added the Azure.Identity label Oct 29, 2021

sadasant commented Oct 29, 2021

View reviewed changes

sadasant added 5 commits October 29, 2021 18:11

a small clarification

70c6255

better wording

613e458

small improvements

4f89d41

skipping final token check on playback because is inconsistent across…

5783f35

… platforms

browser tests dont like dotenv.config

9a5246b

sadasant mentioned this pull request Nov 1, 2021

[core] Added logger parameters to bearerTokenAuthenticationPolicy #18467

Merged

witemple-msft approved these changes Nov 2, 2021

View reviewed changes

sdk/identity/identity/test/msalTestUtils.ts Outdated Show resolved Hide resolved

Update msalTestUtils.ts

f993fe6

Better comment regarding dotenv.config

chlowell reviewed Nov 3, 2021

View reviewed changes

sadasant and others added 6 commits November 2, 2021 20:18

No need for a question mark here.

5bf6e30

Merge remote-tracking branch 'Azure/main' into identity/CAEImprovements

ae9f765

making question marks consistent on a per-file basis

71b6fe1

Merge remote-tracking branch 'Azure/main' into identity/CAEImprovements

7152eed

testing assuming the expiration dates are different -- manually chang…

3b708e4

…ing them on the recordings

the CP1 rename bit me :) I had to change these recordings as well

87cb2c1

another attempt, this time with different token values in the recordings

34c9f08

back to skipping these. The recordings are sound, which is what reall…

c178c40

…y matters

sadasant enabled auto-merge (squash) November 4, 2021 20:56

sadasant merged commit 13c97f3 into Azure:main Nov 5, 2021

sadasant deleted the identity/CAEImprovements branch February 3, 2022 23:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Identity] Ensuring the claims get sent through the getToken requests.#18445

[Identity] Ensuring the claims get sent through the getToken requests.#18445
sadasant merged 36 commits intoAzure:mainfrom
sadasant:identity/CAEImprovements

sadasant commented Oct 29, 2021 •

edited

Loading

Uh oh!

sadasant Oct 29, 2021

Uh oh!

sadasant Oct 29, 2021

Uh oh!

witemple-msft left a comment

Uh oh!

Uh oh!

sadasant commented Nov 2, 2021

Uh oh!

Uh oh!

chlowell Nov 3, 2021

Uh oh!

sadasant Nov 3, 2021

Uh oh!

chlowell Nov 3, 2021

Uh oh!

sadasant Nov 3, 2021

Uh oh!

sadasant commented Nov 4, 2021

Uh oh!

check-enforcer bot commented Nov 4, 2021

Uh oh!

sadasant commented Nov 4, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

sadasant commented Oct 29, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sadasant Oct 29, 2021

Choose a reason for hiding this comment

Uh oh!

sadasant Oct 29, 2021

Choose a reason for hiding this comment

Uh oh!

witemple-msft left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sadasant commented Nov 2, 2021

Uh oh!

Uh oh!

chlowell Nov 3, 2021

Choose a reason for hiding this comment

Uh oh!

sadasant Nov 3, 2021

Choose a reason for hiding this comment

Uh oh!

chlowell Nov 3, 2021

Choose a reason for hiding this comment

Uh oh!

sadasant Nov 3, 2021

Choose a reason for hiding this comment

Uh oh!

sadasant commented Nov 4, 2021

Uh oh!

check-enforcer bot commented Nov 4, 2021

What is Check Enforcer?

Why am I getting this message?

What should I do now?

What if I am onboarding a new service?

Uh oh!

sadasant commented Nov 4, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sadasant commented Oct 29, 2021 •

edited

Loading