search

uchicago / shibboleth-oidc

OpenID Connect support for the Shibboleth Identity Provider v3
Apache License 2.0
81 stars 19 forks source link

Claims not released when "idp.consent.allowPerAttribute" is true #44

Closed mmoayyed closed 1 year ago

mmoayyed commented 7 years ago

Background

Extracted from https://github.com/uchicago/shibboleth-oidc/issues/30 via @dominique-p

Issue

The attribute-release flow was not selected because in our lab installation the property idp.consent.allowPerAttribute had the value true. It is used in an activationCondition for shibboleth.consent.AttributeReleaseFlow in profile-intercept-system.xml (cf. this link )

After setting idp.consent.allowPerAttribute to the default false the simple-web-app/user page now shows all the claims that are available!

I was blinded because when using Shibboleth/SAML to authentify for a SP then the attribute-release flow was selected anyway. It means then that the other part of the OR in the activateCondition (net.shibboleth.idp.saml.profile.config.logic.IncludeAttributeStatementPredicate) behaves differently for oidc (evaluates to false):

Reproduce

set idp.consent.allowPerAttribute to true and observe that the attribute release flow is not selected and the claim list is not constructed , as well as, in the Shibboleth/SAML case, the attribute release flow is still selected.

Diagnosis

This explanation about the activateCondition of the attribute release flow might shed some light on this issue:

puzzled about the activationCondition of the AttributeReleaseFlow http://shibboleth.1660669.n2.nabble.com/puzzled-about-the-activationCondition-of-the-AttributeReleaseFlow-td7631029.html

There is also a warning note on the ConsentConfiguration page of the Shibboleth documentation that gives some context:

From Scott Cantor: in case the attribute release flow is not applicable then the attributes that passed the filter policy should be transmitted to the client.