Decide on whether "id" attributes are mandatory for attribute filter rules
Description
Environment
Activity
Documentation is in progress. I'm currently either saying "don't" or not mentioning references.
I've entered #idp-656 for the documentation/rationalizion effort mentioned above
We are done here for V3.0.0
For V.next we might want to follow my plan as above.
Rule References will be left undocumented in 3.0.0 As we document the rule reference, if some missing functionality makes the documentation hard we will add a RFI for them
Marking against 3.0.0 so we close before release.
Note that discussion about this all starts here: http://shibboleth.net/pipermail/dev/2013-June/002210.html
My current plan is to
1) Warn on all use of reference. This never worked in V2 (because the code looked for the embedded text, but the schema required ref="whatever").
2) Leave the Id autogeneration entirely as is - to allow us to completely fit in reference if we want to at a later date, or even before V3 ships. I'll enter a case targeting a release after 3.0 for fixing this.
3) Separate out the LogPath from the Id (all the Attribute filter code uses getLogPath'{}' and in the parser use the Id if present and anonymous text if it isn't.
4) Remove the warning entirely.
I think we need to get rid of all ID defaults.
Either we require IDs, or the logging allows for no IDs and just doesn't include any mention of them when they're not set. I would rather conditionally log and just code around the lack of an ID than default them.
I'm filing this to make sure that the discussion in http://shibboleth.net/pipermail/dev/2014-July/004791.html is coming to a clear decision.
Currently, when loading the sample
attribute-filter.xml
, the log will haveINFO [net.shibboleth.idp.attribute.filter.spring.AttributeFilterPolicyParser:82] - Parsing configuration for attribute filter policy releaseSomeAttributeToAnyone INFO [net.shibboleth.idp.attribute.filter.spring.BaseFilterParser:139] - Element 'PolicyRequirementRule' did not contain an 'id' attribute. Generated id '/AttributeFilterPolicyGroup:ShibbolethFilterPolicy/PolicyRequirementRule:_cfd4fad01c14c14e1ce7fe3fe393d8ed' will be used INFO [net.shibboleth.idp.attribute.filter.spring.BaseFilterParser:139] - Element 'AttributeRule' did not contain an 'id' attribute. Generated id '/AttributeFilterPolicyGroup:ShibbolethFilterPolicy/AttributeRule:_080fd276ecaab742d34cc7744a4ec2aa' will be used
I.e., for every
PolicyRequirementRule
,AttributeRule
,PermitValueRule
etc. which lacks an id attribute, there's a log message at INFO level which prints the qualifiedId which is generated in case.According to the current schema definition (http://svn.shibboleth.net/view/java-identity-provider/trunk/idp-schema/src/main/resources/schema/shibboleth-afp.xsd?revision=6319&view=markup#l195, see also the one for IdPv2), the id attribute is optional (
use="required"
is absent). I would be in favor of keeping it this way, and lower the log level toDEBUG
, in consequence. (Having to add an id attribute to each and every rule makes the filter syntax fairly baroque, without an apparent benefit, I think. And just to be clear: I'm fine with requiring an id on theAttributeFilterPolicy
element [i.e. the parent], but consider it overkill for all its children.)