docs: WithClientClaims API design for NSP claims support#5982
docs: WithClientClaims API design for NSP claims support#5982Robbie-Microsoft wants to merge 2 commits into
Conversation
Captures the proposed approach for supporting client-originated claims (NSP/Network Security Perimeter) across MSIv1, MSIv2, cert-based, and FIC auth flows. Documents the current state of each flow, the gap in the existing WithClaims() API, and the design for a new WithClientClaims() API with proper cache keying. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
|
||
| Azure Redis Cache operates in a Backing resource VM/VMSS and uses MSAL with Managed Identity credentials to acquire tokens from ESTS. The Redis team has requested that MSAL support sending NSP (Network Security Perimeter) claims to IMDS, so that the resulting tokens contain the NSP claim required to access NSP-protected resources. | ||
|
|
||
| This document proposes a new `WithClientClaims()` API to support this scenario in a consistent, safe, and harmonized way across all MSAL auth flows. |
There was a problem hiding this comment.
Why "new"? WithClientClaims() is existing supported API right?
There was a problem hiding this comment.
Yeah, WithClientClaims() already exists as an obsolete api. Adding overloads here will make it not obsolete anymore, which can be confusing.
There was a problem hiding this comment.
Clarified in the latest design doc commit (bd2eed1). The existing obsolete WithClientClaims is an app-level method on ConfidentialClientApplicationBuilder that takes (X509Certificate2, IDictionary<string,string>, ...) — it signs extra claims into the client assertion JWT. The new API described here is a request-level method that takes (string claimsJson) and lives on the request builders. They're on different classes with different signatures and coexist without C# ambiguity. The obsolete app-level overload is unaffected. Added a naming note to the design doc explaining this.
There was a problem hiding this comment.
Ok cool. so it should be alright then.
- Clarify that the new WithClientClaims(string) request-level API coexists without conflict with the existing obsolete app-level WithClientClaims (X509Certificate2, IDictionary) — different classes, different signatures - Add NSP SDK call-site code snippet showing claims sourced at request time, making the request-level design concrete and demonstrating why app-level placement would not support dynamic enforcement-mode changes - Add explanation of why per-request placement is correct: enforcement mode changes produce new claims; request-level avoids needing to recreate the app Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3 participants
Summary
Design document for the proposed WithClientClaims() API to support client-originated claims (NSP / Network Security Perimeter) across MSIv1, MSIv2, cert-based, and FIC auth flows.
What's in this doc
Context
Stemming from a discussion with the MSI team (Azure Redis Cache) requesting MSAL support for NSP claims. Please add comments directly to the doc.
Open questions needing input