SubjectConfirmationData Recipient always uses default

[ubamrein]

After long hours of browsing, I could not find any reference to how one can specify the Recipient of the SubjectConfirmationData within the Saml-Assertion generated.

Our use case involves transforming a JWT-Bearer Token from Azure to a valid SAML-Assertion, which we can use to retrieve an access-token on an SAP endpoint. Since the corresponding App-Registration is used for multiple different web services, the configuration includes multiple Reply-URLs. We could not find a way to specify, via a parameter in the request, the specific Reply-URL, which in the transformation process is used as a value for the Recipient field in the SubjectConfirmationData.

The documentation states

SubjectConfirmationData for a SAML assertion sourced from an OBO call: If the target application requires a recipient value in SubjectConfirmationData, then the value must be a non-wildcard Reply URL in the resource application configuration.

but gives no hint whatsoever on how to specify a specific one.

In the end we found a solution by providing an index to the redirect_uri we need for the transformation service, which works in our case, since we only need to use one such service. Since this is based on a subtle configuration within the portal, which easily and unintentionally could be change, it should be possible, to supply the redirect_uri via the request (as it is also normal for any oidc flow for example).

Supplying the redirect_url parameter in the request does not produce an error, but also does not yield the needed recipient -- it is simply ignored.

If there is a way to provide the redirect_uri then this should be mentioned in the documentation, or otherwise the noted that it is only possible for one service (the workaround we use).

Thanks in advance

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1d91ee0b-7926-c0ad-aca2-48958c81acf3
• Version Independent ID: 9fa490aa-49e4-8034-83c2-d6c8517834da
• Content: Microsoft identity platform and OAuth2.0 On-Behalf-Of flow - Microsoft Entra
• Content Source: articles/active-directory/develop/v2-oauth2-on-behalf-of-flow.md
• Service: active-directory
• Sub-service: develop
• GitHub Login: @nickludwig
• Microsoft Alias: ludwignick

[JamesTran-MSFT]

@ubamrein Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

[nickludwig]

reassign:sreyanth

[Sreyanth]

@ubamrein Thanks for your feedback. From what I know, the first non-wildcard reply URL will be used for the Recipient attribute. Can you clarify the workaround you mentioned? Did you pass an index to the redirect_uri (say 1 to select the second URL)?

[ubamrein]

Well we could not figure out how to select the URL via the redirect_uri parameter, or at least in our case it did not yield any results. But to be fair, we only ever tried it with an URL and not with an index.

In the end we changed the index in the azure portal, such that our wanted URL was at index 0, which I guess makes it the first non-wildcard reply URL (so your guess seems about right).

[Sreyanth]

Thanks for confirming. I updated our docs to clarify the behavior.