Debugging SAML to OIDC ACR proxying

[Wessel, Keith]

Thanks for this, Phil. FWIW, even after adding:

<logger name="net.shibboleth.oidc.security" level="DEBUG"/>

to logback.xml, I still don't see any of the events in the logs that you described. I did see the outbound request in the logs with the acr_values HTTP parameter and the appropriate value of c1 getting passed to Entra. But I can't see what's coming back in the tokens. It's not getting logged.

I'm not sure, however, if that's going to help me anyway in this case. Wondering if anyone is successfully doing OIDC with ACR signaling a Shib IdP proxying to Entra with OIDC.

The current issue is that Microsoft doesn't seem to be following the spec, as shocking as that may be.

Entra doesn't have claims_parameter_supported present, let alone set to true, in their OP metadata for my tenant. If they did, we found examples on the web where people are passing in a claims parameter in the authorize request for acr marked as essential. They accept it, but their metadata doesn't advertise it, and thus Shibboleth doesn't try because the spec says not to.

We're still struggling to see why Entra doesn't seem to be trying to satisfy the request sent in using the acr_values query parameter, but even if it would, that's not going to help us since that's an optional request, anyway. If our intent is to force MFA and the user isn't eligible for MFA, Entra will just return the user without satisfying MFA and obviously without the acr claim in the response.

I'd welcome any thoughts or recipes from anyone who got this working.

Thanks,
Keith

From: users <users-bounces at shibboleth.net> On Behalf Of Philip Smart via users
Sent: Friday, March 6, 2026 11:09 AM
To: Shib Users <users at shibboleth.net>
Cc: Philip Smart <Philip.Smart at jisc.ac.uk>
Subject: Re: Debugging SAML to OIDC ACR proxying

Hi Keith

| Simple question: what logging class can I turn up that would show me the ACR being sent to Microsoft in the request?

The OIDC/OAuth message encoders should show the parameters of the request if you set idp.loglevel.messages to DEBUG and find the log line with category [PROTOCOL_MESSAGE.OAUTH2]. If the OP supports the claims parameter, the ACR values should be inside the claims parameter; else, they will be inside the acr_values parameter. If you use a request object, the ACR values will be inside the request object, and you will need to decode the base64URL encoded JWT from the request parameter to find them.

| And what class would show me what's coming back?

Sadly, the same logging does not exist on the decoders, but it should [1]. However, for now, there are less elegant ways of logging the raw id_token by using a logger for the category net.shibboleth.oidc.security and setting it to DEBUG. In particular, the BaseSignedJWTTrustEngine should log the base64url encoded JWT, which you can decode.

Let me know how you get on, it is possible the RP is not behaving correctly, and we will need to fix something.

Phil

[1] https://shibboleth.atlassian.net/browse/JCOMOIDC-158<https://urldefense.com/v3/__https:/shibboleth.atlassian.net/browse/JCOMOIDC-158__;!!DZ3fjg!7lIl8qRcVfqfdK1W9RBiFbbJlS7fQrm35ZFr0HW0WPMrBkeSM2IEOsPtqMO5tuo3pSpzSx5FrP5yHjyGfU0J$>




Jisc is a registered charity (in England and Wales under charity number 1149740; in Scotland under charity number SC053607) and a company limited by guarantee registered in England under company number 05747339, VAT number GB 197 0632 86. Jisc's registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.

For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice<https://urldefense.com/v3/__https:/www.jisc.ac.uk/website/privacy-notice__;!!DZ3fjg!7lIl8qRcVfqfdK1W9RBiFbbJlS7fQrm35ZFr0HW0WPMrBkeSM2IEOsPtqMO5tuo3pSpzSx5FrP5yHpWDiuyf$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260311/10c81adf/attachment.htm>