OIDC in 4.1.0 and problems with claims

[Darren Boss]

I got a bit further after changing this in relying-party.xml default
configuration:
<bean parent="OIDC.SSO" p:postAuthenticationFlows="attribute-release" />
to just this:
<ref bean="OIDC.SSO"/>

I'm seeing the claims on the other side now, no errors or related
warnings in the logs now.

If having a post authentication flow with attribute-release for OIDC
is possible, I would expect to see instructions in this section of the
plugin docs perhaps?
https://wiki.shibboleth.net/confluence/display/IDPPLUGINS/OPProfileConfiguration

Your comment about "you can also toggle an option to store the record
in the access token" rings a bell. I did come across that somewhere in
the docs. My goal is to get attribute release consent working for at
least a subset of my registered OIDC clients.

On Tue, Apr 6, 2021 at 4:09 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> Attribute consent? Stored where?
>
> The back channel calls honor consent, but they have to find the records to do that, or I believe you can also toggle an option to store the record in the access token so that in theory it allows for client storage with it.
>
> I don't know how to disable the check if you don't have consent on, but it may be an issue of defaults not lining up like they should, though that's somewhat irrelevant for an upgrade. If consent isn't on (*), then you'd presumably have to disable the check for that on the back channel.
>
> This did change in the new code because it wasn't implemented correctly on the back-channel before.
>
> -- Scott
>
> (*) Yes, I'm aware the spec "requires" consent, but that's obviously nonsense, it's unenforceable and never belonged in the protocol itself.
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



-- 
Darren Boss
Senior Programmer/Analyst
Programmeur-analyste principal
darren.boss at computecanada.ca