OIDC claims missing after upgrade to IdP 4.1

[Wessel, Keith]

Thanks, Scott. I turned off the consent flow for the OIDC SSO bean, and sure enough, everything's working. Consent for OIDC clients isn't a must for us right now. It will be, but not yet. So, I can roll with this. But I'll definitely turn up logging and pull out some relevant log entries for a bug tomorrow.

As to your comment:

> As long as a database is involved for consent, make sure none of the options to encode attributes into the tokens are being used to avoid a lot > of extra code running. It should be able to look up the consent decisions on the back channel and enforce them there.

We do use a database for storing consent decisions, but obviously, the consent post authentication flow isn't enabled for any of the token or userinfo non-browser profiles. I think I'm missing your point, though, on this. Can you explain, please?

Thanks,
Keith

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, July 20, 2021 5:50 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: OIDC claims missing after upgrade to IdP 4.1

On 7/20/21, 6:36 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    Thanks, Scott. Yes, I'm expecting to see them in the userinfo 
> response, not the idtoken. I'll try turning off consent to see if that 
> helps. I am still seeing that strange uncaught exception that I posted to the list last week related to consent. So, that could quite possibly be the issue.

Well, I imagine that's it, but I have no idea what the bug is, other than an uncaught exception is always a bug so there's no point not filing one.

>    If that doesn't help, do you know what class I'd turn up logging 
> for if I wanted to see details on the processing for the OIDC attribute filtering?

The new plugins are under net.shibboleth.idp.plugin.oidc.op.attribute.filter, the old ones are the same as always.

As long as a database is involved for consent, make sure none of the options to encode attributes into the tokens are being used to avoid a lot of extra code running. It should be able to look up the consent decisions on the back channel and enforce them there.

All else failing, turn everything but Spring up high and attach it to a bug about the exception. I just doubt there will be much help for a few weeks.

-- Scott


--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!pSQX5kdymncuMcu0mfWY8w-wAAgJKI_CsbpbTFwhXM2knnDIhtqZW-58R8-gVPAQtw$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net