Accessing RequestedAttributes in MappedEntityAttribute

[Cantor, Scott]

> We could not find a pre-defined condition that would
> evaluate whether  the SP metadata has a specific
> RequestedAttribute (equivalent of  attribute-filter
> AttributeInMetadata rule).

That's true, but it’s also true that we consider the ability to write those in Java to be a basic skill for anybody running the IdP as we can't pre-define every possible piece of logic somebody might need.

> However, through experimentation, we found that the
> MappedEntityAttributes predicate also responds to Tag
> Candidates  matching the SAML2 names of
> RequestedAttribute entries from the SP metadata.

It shouldn't be. I just checked the code and the Predicate only looks at the mapped objects that are contained at the EntityDescriptor or EntitiesDescriptor levels.

The mappings extracted for RequestedAttributes end up inside the AttributeConsumingService object that contains them and the predicate doesn't check for that.

The objects are the same and the logic to decode them is the same, but the Predicate just doesn't check there.

Additionally, it should only be checking the EntityAttributes extension results because we only have Metadata Filtering to strip those. So if it does check RequestedAttributes (and it can't be, the code just isn't there to look at them), it would open an avenue of undue influence over tags by a remote metadata source.

Another difference is the automation. Only RequestedAttributes with explicitly defined decoding rules will be decoded. EntityAttributes get auto-decoded if the NameFormat is URI.

So in practice it's fairly safe, one doesn't normally create decoding rules for all the tags we use routinely as they aren't user attributes.

But no, I think you're mistaken about what it's doing.

Obviously an ActivationCondition of that sort could be built, or the existing one extended to check there.

-- Scott