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" ?

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?

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?

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 ?

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?

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?

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?

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?

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?

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?

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

Uh oh!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants