Expose suppressDisplayInformation as a resolver plugin option

Basics

Logistics

Basics

Logistics

Description

Maybe this is being used somehow already but I can't find anything. Just close if I'm missing something.

There's a suppressDisplayInformation flag in AbstractResolverPlugin that blocks display metadata attachment to IdPAttributes. It appears that it got added as a partial? fix for https://shibboleth.atlassian.net/browse/IDP-1576#icft=IDP-1576 but I can't see where it's being used or how, but it seems useful to me when people aren't using consent.

Would it make sense to wire this up as an option, maybe globally on the resolver (might not be possible depending on ordering of initialization) or at least in the schema for the plugins?

I was also thinking it should be auto-set for dependencyOnly attributes.

Environment

None

Activity

Show:

Rod Widdowson June 6, 2021 at 2:02 PM

RN added.

Rod Widdowson June 6, 2021 at 11:43 AM

Reopening to log work and close

Rod Widdowson May 8, 2021 at 1:20 PM

This work is complete, the new property is documented.

NOTE that before this case can be closed an appropriate release note needs to be writte,

Rod Widdowson May 5, 2021 at 4:05 PM

Change of plan.

It turns out that it is pretty simple to do https://shibboleth.atlassian.net/browse/IDP-1817#icft=IDP-1817 so that is now done (bar deprecation and removal of all old methods). This means that there is now no need to do any addition of DisplayName and DisplayDescription during attribute resolution.

Given that it seems needless to have per plugin control with all the attendant Schema changes which would then have to be backed out. Rather, I have implemented per IdP resolver control (via a property called idp.service.attribute.resolver.suppressDisplayInfo)

The property defaults to false - which is to say that the values are still added by default, even though this adds nothing to the system except sucking up CPU time - unless someone is actually playing with these values - for instance by adding to them in a script. Adding values in a script will current have not effect because of this change which we may want to revisit.

I really want to flip the default, because it will allow us to add deprecation warnings to the IdPAttribute methods with a view to easy removal in 5.0, It also provides an easy way to continue to support the (entirely broken) "add DisplayInfo in a script" thing I allude to above

I'll add a note to discuss this on Friday, but I suspect that that is a change too far.

Rod Widdowson May 4, 2021 at 4:28 PM

Adding an XML suppressDisplayInformation attribute to the DataConnector and AttributeDefinition code was easy. As was making dependencyOnly Attribute Definitions set that the field true (subject to explicit override by the XML attribute).

Adding a global override, although important, is slightly grubbier.

Although the attribute resolver is the natural place for this boolean to reside, it would currently be consulted within the AttributeDefinition (Data Connectors attributes are handles inside the resolver because of historic API/IMPL issues).

The code is not complex to move the function from the Attribute Definition up into the Attribute Resolver, but this feels mightily close to breaking the API contract.

Bearing in mind that, courtesy of https://shibboleth.atlassian.net/browse/IDP-1817#icft=IDP-1817 all this code is slated to go away in V5.0 I am currently of the belief that the best interim solution is to add a field to the Work Context (which is not for public consumption) and use that inside the attribute definition to decide whether to add the info.

But I need to mull on this some more.