attribute ID instead of displayName shown in consent view for OIDC
Description
Environment
Platform: RHEL8
Application server: Jetty 9.4.39
Java: Amazon Corretto 11.0.10
The platform Apache httpd is proxying to the application server.
The IdP is a fresh 4.1.0 install. No upgrading involved.
is related to
Activity
Rod Widdowson May 5, 2021 at 3:53 PM
@Henri Mikkonen Worth noting that in https://shibboleth.atlassian.net/browse/IDP-1817#icft=IDP-1817 and https://shibboleth.atlassian.net/browse/IDP-1811#icft=IDP-1811 I have removed the need for this. But this is not in mainline yet and is slated for 4.2.
Scott Cantor April 30, 2021 at 4:17 PM
In that event, people can also workaround the issue by adding the corrected beans file to the right spot under WEB-INF/classes.
Henri Mikkonen April 30, 2021 at 12:31 PM
Finally found the cause for this issue. The ResolveAttributes SWF action bean declaration for OIDC flows was simply missing transcoderRegistry -property:
<bean id="ResolveAttributes" class="net.shibboleth.idp.profile.impl.ResolveAttributes" scope="prototype"
c:resolverService-ref="shibboleth.AttributeResolverService"
p:maskFailures="%{idp.service.attribute.resolver.maskFailures:true}" />That caused AbstractResolverPlugin.addDisplayInformation -method not to set the display names / descriptions. The method was actually logging about it nicely "No transcoder registry supplied, unable to attach displayName/description metadata" - but the DEBUG level made it harder to catch.
The issue is solved by adding:
p:transcoderRegistry-ref=_"shibboleth.AttributeRegistryService"_
to the bean declaration.
Scott Cantor April 29, 2021 at 12:58 PMEdited
(Edit: I think I'm mistaken, looks like 1576 was "fixed" but left open for future refactoring, so I guess exporting should still get the right result.)
More related: I do want to note that https://shibboleth.atlassian.net/browse/IDP-1576#icft=IDP-1576 is still open. I believe that exported attributes from data connectors may still not have the display metadata attached, and that only happens for actual AttributeDefinition-sourced attributes. Since many examples and files were redone to rely on exporting connectors (not to mention I turned consent off by default), I just wanted to make sure it's not something obvious. That wouldn't fit a SAML vs. OIDC observation....but nothing does. Nothing about this makes a lot of sense since all the attribute layers are common to both and all the code for this is in base classes.
Scott Cantor April 29, 2021 at 12:42 PM
Unrelated, but wow that's an insane volume of logging even for DEBUG. I would suggest adjusting that and making DEBUG just log the attribute IDs and the full map dumps on TRACE. JMHO. I don't use consent, but if I did, I would have changed that a long time back.
The consent view does not show displayName for OICD claims. The attribute ID is shown instead.
Doesn't matter if the whole attribute including displayNames, descpriptions and the encoder is defined in the resolver or the attribute registry is used for displayNames, descriptions and the transcoder.
Debug logging confirms that PopulateAttributeReleaseContext does not populate displayNames or displayDescriptions.
The consent view works fine with SAML.