Applying consent to back-channel uses the wrong attribute names
Description
Environment
is related to
Activity
Henri Mikkonen May 18, 2021 at 12:30 PM
The bug was still existing when the consent is encoded into tokens (i.e. property _idp.oidc.encodeConsentInTokens_ set to true). Now fixed.
Henri Mikkonen March 22, 2021 at 3:13 PM
Refactored as a part of https://issues.shibboleth.net/jira/browse/JOIDC-37
Scott Cantor December 4, 2020 at 3:24 PMEdited
Per the call, I think the unintended use of the ConsentContext warrants reworking this to avoid use of that context (the SAML flows don't use AFAIK). On the back-channel, Tom built an interceptor that's sort of used as a directly called subflow to read the previous consent record back out and apply that to the attribute context, and I think that's what should be done.
The SAML AttributeQuery flows call that flow so this should be pretty copyable.
Henri Mikkonen December 4, 2020 at 2:51 PM
I reviewed the code in detail and there’s indeed wrong logic in the use of identifiers in consent records (consentable & consented) vs filtering the corresponding values in the backend endpoints (token & userinfo). It doesn’t affect to the claim values that are encoded in the authorization code or access/refresh tokens, but when the claim values are resolved by attribute engine during the backend call, then the consent is verified only against the claims whose claim names (produced by transcoders) match with the attribute IDs. This may be a problem at least if consent is implemented per attribute/claim, and the end-user has been able to deny individual claims to be released by OP.
I believe the back-channel token flows rely on pulling out consent records to apply consent to the claims before including them, but the logic there is confusing the IdPAttribute IDs with the eventual claim names used after encoding is done.
The consent records have the former and the filtering assumes they're the latter, so unless they line up by accident, you either don't get many claims in the tokens or you'd potentially have a claim included by mistake if the deployer did something odd that caused an encoded name to match a different but non-consented IdPAttribute.
We do have a sort of interceptor flow that Tom built to enforce consent on queries, we might be able to just reuse that the same way. Or failing that, the logic just needs to move earlier on and run against the AttributeContext normally to filter out the attributes before they get turned into claims.