OIDC in 4.1.0 and problems with claims

[Darren Boss]

So client side storage of attribute release consent is not practical
for OIDC or in any context? It doesn't work well because people may
use different clients/browsers? I guess I need more context.

I currently have two instances of the IdP running and use cookies for
sticky sessions so I have the problem that anyone has when running a
clustered IdP. It's probably overkill to run multiple replicas in our
case but it does help when rolling out a new configuration or a
newer/rebuilt container since there will always be at least one
instance running at all time.

On Wed, Apr 7, 2021 at 8:59 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 4/7/21, 8:56 AM, "users on behalf of Darren Boss" <users-bounces at shibboleth.net on behalf of darren.boss at computecanada.ca> wrote:
>
> >    RIght, it wasn't in the docs but in the comment above the
> >    idp.oidc.encodeConsentInTokens line in oidc.properties
> >    # Store user consent to authorization code & access/refresh tokens
> >    instead of exploiting consent storage
>
> Yes, I added it to the profile settings page for the Authorization flow.
>
> >    So, try setting encodeConsentInTokens to true and enabling the consent
> >    post login flow again?
>
> If you want to test it pathologically, yes, that's supposed to work. It's a lot of code to support something that's not really practical, but...
>
> -- Scott
>
>
> --
> 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