Document caching strategy for Managed Identity v2 #5526

gladjohn · 2025-10-08T15:43:17Z

Added detailed caching strategy and resilience plan for Managed Identity v2, including problem identification, proposed solutions, call sequence, cache renewal matrix, invalidation rules, and security considerations.

bgavrilMS · 2025-10-09T12:53:35Z

docs/msi_v2/caching_strategy.md

+---
+
+## Solution (What’s Changing)
+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.


what is "link-local" ?

just the local endpoint

bgavrilMS · 2025-10-09T12:54:24Z

docs/msi_v2/caching_strategy.md

+
+## Solution (What’s Changing)
+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.
+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.


What does it mean "treat as primary anchor". Pls use more precise wording.

bgavrilMS · 2025-10-09T12:54:54Z

docs/msi_v2/caching_strategy.md

+
+## Solution (What’s Changing)
+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.
+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.


We should not hardcode any expirations. We rely on services returning expirations.

bgavrilMS · 2025-10-09T12:55:40Z

docs/msi_v2/caching_strategy.md

+## Solution (What’s Changing)
+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.
+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.
+3. **Proactive renewal at half-life (+ small jitter)** to rotate well before expiry.


Pls be precise. Specify:

jitter (e.g. 5 min)

if renewal should happen on front-end or back-end thread. I think front-end.

How is jitter calculated? Is it randomized per host/process or globally coordinated? Could jitter introduce any unintended renewal delays?

bgavrilMS · 2025-10-09T12:56:50Z

docs/msi_v2/caching_strategy.md

+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.
+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.
+3. **Proactive renewal at half-life (+ small jitter)** to rotate well before expiry.
+4. **Single-writer coordination** so only one process issues/renews; others reuse the same cert.


If you want cross-process coordination, please specify the IPC that is going to be used. This needs to exist on Windows and Linux and it needs to be available in sanctioned libraries across all supported MSAL languages.

How is the ‘single-writer’ selected? Is this a file lock, named mutex, or other mechanism? What happens if the single-writer crashes mid-renewal?

Yes, this is cross‑process (shared file + shared cert store),

bgavrilMS · 2025-10-09T12:57:51Z

docs/msi_v2/caching_strategy.md

+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.
+3. **Proactive renewal at half-life (+ small jitter)** to rotate well before expiry.
+4. **Single-writer coordination** so only one process issues/renews; others reuse the same cert.
+5. **MAA token** is used **only** for issuance/renewal; short-lived cache to prevent attestations calls.


Not enough precision. What does it mean "short-lived" cache?

What’s the cache invalidation logic if a policy or key rotation occurs on the MAA side? Is there a way to force re-attestation?

Not enough precision. What does it mean "short-lived" cache?

Added details to it

What’s the cache invalidation logic if a policy or key rotation occurs on the MAA side? Is there a way to force re-attestation?

MSAL creates the key, and sends to MAA for attestation.

bgavrilMS · 2025-10-09T12:58:11Z

docs/msi_v2/caching_strategy.md

+```
+Call 0 (local): Probe IMDS v2 → cache MSI source (V2/V1)
+1       (local): Create KeyGuard key (per reboot)
+2       (external): Get MAA token  // only for (re)issuing cert


what is local and what is external ?

local is IMDS endpoints (link-local) or local to the machine. external is ESTS/MAA, in this case.

bgavrilMS · 2025-10-09T13:05:47Z

docs/msi_v2/caching_strategy.md

+| Item | Scope | Where | TTL | Notes |
+|---|---|---|---|---|
+| **MSI v2 probe result** | Per process | In-proc static | Process lifetime | NO changes needed here |
+| **MAA token** | Per **keyHandle** | small file cache | ≤ JWT `exp` (~8h) | Only for cert issuance; evict on reboot/policy change/attest fail; refresh half-life + jitter |


How are you going to deal with atomicity, multiple file writers, and a process that gets killed in the middle of a write?

Updated the MAA token row

bgavrilMS

Not enough details.

Robbie-Microsoft

For each cache and renewal step, document what happens if the cache is missing, invalid, or corrupted.
Outline (even briefly) the implementation details of the single-writer system.

Robbie-Microsoft · 2025-10-15T20:37:23Z

docs/msi_v2/caching_strategy.md

+# Managed Identity v2 (Attested TB) — Resilience & Caching Plan
+
+## TL;DR
+We reduce cold-start latency and dependency risk for MSI v2 by caching safe, long-lived artifacts, coordinating renewal across processes, and keeping the hot path in memory. **MAA is used only to (re)issue the binding certificate**; bound AT acquisition relies on that cert. Result: fewer failures, less churn, smoother CX.


What’s the fallback if the binding cert is lost or corrupted? Is there any emergency recovery path?

Robbie-Microsoft · 2025-10-15T20:39:39Z

docs/msi_v2/caching_strategy.md

+## Solution (What’s Changing)
+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.
+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.
+3. **Proactive renewal at half-life (+ small jitter)** to rotate well before expiry.


How is jitter calculated? Is it randomized per host/process or globally coordinated? Could jitter introduce any unintended renewal delays?

Robbie-Microsoft · 2025-10-15T20:40:19Z

docs/msi_v2/caching_strategy.md

+1. **Probe once** (link-local) to detect **MSI v2** → cache result **in-proc**.
+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.
+3. **Proactive renewal at half-life (+ small jitter)** to rotate well before expiry.
+4. **Single-writer coordination** so only one process issues/renews; others reuse the same cert.


How is the ‘single-writer’ selected? Is this a file lock, named mutex, or other mechanism? What happens if the single-writer crashes mid-renewal?

Robbie-Microsoft · 2025-10-15T20:40:43Z

docs/msi_v2/caching_strategy.md

+2. Treat the **binding certificate** (from IMDS `/issuecredential`) as the **primary anchor** (~7-day validity); use it to get ATs.
+3. **Proactive renewal at half-life (+ small jitter)** to rotate well before expiry.
+4. **Single-writer coordination** so only one process issues/renews; others reuse the same cert.
+5. **MAA token** is used **only** for issuance/renewal; short-lived cache to prevent attestations calls.


What’s the cache invalidation logic if a policy or key rotation occurs on the MAA side? Is there a way to force re-attestation?

Robbie-Microsoft · 2025-10-15T20:42:30Z

docs/msi_v2/caching_strategy.md

+```
+Call 0 (local): Probe IMDS v2 → cache MSI source (V2/V1)
+1       (local): Create KeyGuard key (per reboot)
+2       (external): Get MAA token  // only for (re)issuing cert


Are there retries or backoff strategies if the MAA call fails? Is exponential backoff used or is it a fixed retry policy?

updated details please check

Robbie-Microsoft · 2025-10-15T20:43:36Z

docs/msi_v2/caching_strategy.md

+| Item | Scope | Where | TTL | Notes |
+|---|---|---|---|---|
+| **MSI v2 probe result** | Per process | In-proc static | Process lifetime | NO changes needed here |
+| **MAA token** | Per **keyHandle** | small file cache | ≤ JWT `exp` (~8h) | Only for cert issuance; evict on reboot/policy change/attest fail; refresh half-life + jitter |


How are policy changes detected? Is it polled, pushed, or inferred from failures?

We don’t poll.

We don’t get a push.

We infer from failures: when MAA/IMDS/eSTS return specific attestation/policy/key errors, we treat that as “policy changed, invalidate cache and re‑attest”.

Robbie-Microsoft · 2025-10-15T20:46:26Z

docs/msi_v2/caching_strategy.md

+|---|---|---|---|---|
+| **MSI v2 probe result** | Per process | In-proc static | Process lifetime | NO changes needed here |
+| **MAA token** | Per **keyHandle** | small file cache | ≤ JWT `exp` (~8h) | Only for cert issuance; evict on reboot/policy change/attest fail; refresh half-life + jitter |
+| **Binding cert + `/issuecredential` metadata** | Per **Managed Identity per user context** | Persisted (Win: `CurrentUser\My`; Linux: protected file/PEM) | ~7 days | Renew at **half-life + jitter**; Serialize issuance |


What protects against file corruption or unauthorized access on Linux? Is there a fallback if the file is deleted outside of MSAL?

There’s no MAA on Linux, so the only persisted artifact there is the binding cert + metadata.

if that file is deleted or corrupted outside MSAL, the next read fails validation and we just treat it as a cache miss

Robbie-Microsoft · 2025-10-15T20:46:51Z

docs/msi_v2/caching_strategy.md

+| **MSI v2 probe result** | Per process | In-proc static | Process lifetime | NO changes needed here |
+| **MAA token** | Per **keyHandle** | small file cache | ≤ JWT `exp` (~8h) | Only for cert issuance; evict on reboot/policy change/attest fail; refresh half-life + jitter |
+| **Binding cert + `/issuecredential` metadata** | Per **Managed Identity per user context** | Persisted (Win: `CurrentUser\My`; Linux: protected file/PEM) | ~7 days | Renew at **half-life + jitter**; Serialize issuance |
+| **Access tokens (`bearer` or `mtls_pop`)** | Per audience | In memory | Service-configured | Reacquire after reboot (new key) |


Are there scenarios where token invalidation lags behind key rotation? How does the system ensure that stale tokens aren’t accidentally reused?

not sure, I understand this. When do we rotate keys?

Robbie-Microsoft · 2025-10-15T20:47:11Z

docs/msi_v2/caching_strategy.md

+## Invalidation Rules
+- **Reboot** → Use **persisted binding cert** to fetch new ATs; re-attest on first demand on service failure.
+- **Cert expiry** → re-issue.
+- **MAA token expired** → re-attest and re-issue.


Are there built-in safeguards to prevent a thundering herd if all processes notice expiry at the same time?

Robbie-Microsoft · 2025-10-15T20:49:03Z

docs/msi_v2/caching_strategy.md

+
+  ## Why This Improves CX
+- **MAA is out of the hot path**—steady-state calls rely on a **multi-day binding cert**.
+- Different identities on the same VM, uses **cached MAA token**


Is the cache not keyed per identity?

it is, updated

Updated the caching strategy for MSI v2 to enhance resilience and reduce cold-start latency. Key changes include improved certificate renewal processes and better caching mechanisms.

Document caching strategy for Managed Identity v2

1ba816e

Added detailed caching strategy and resilience plan for Managed Identity v2, including problem identification, proposed solutions, call sequence, cache renewal matrix, invalidation rules, and security considerations.

gladjohn requested a review from a team as a code owner October 8, 2025 15:43

bgavrilMS reviewed Oct 9, 2025

View reviewed changes

bgavrilMS requested changes Oct 9, 2025

View reviewed changes

Robbie-Microsoft requested changes Oct 15, 2025

View reviewed changes

gladjohn added 3 commits November 15, 2025 13:07

Revise MSI v2 caching strategy for resilience and efficiency

2cae747

Updated the caching strategy for MSI v2 to enhance resilience and reduce cold-start latency. Key changes include improved certificate renewal processes and better caching mechanisms.

Update caching_strategy.md

7a995e9

Update caching_strategy.md

d90e6af

gladjohn requested review from Robbie-Microsoft and bgavrilMS November 17, 2025 19:47

Robbie-Microsoft approved these changes Nov 17, 2025

View reviewed changes

Document caching strategy for Managed Identity v2 #5526

Are you sure you want to change the base?

Document caching strategy for Managed Identity v2 #5526

Uh oh!

Conversation

gladjohn commented Oct 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bgavrilMS left a comment

Choose a reason for hiding this comment

Uh oh!

Robbie-Microsoft left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers