Remove (in the IdP) or implement the AttributeScopeMatchesShibMDScope filter
Description
Environment
Activity
Removed from Documentation
Removed from schema.
Obviously the SP has all this decoder functionality, and a syntax for configuring it.
The filter in the SP does operate on the SP equivalent of IdPAttribute, rather than SAML directly.
It can be a bit brain twisting at times, but in practice it does work, and with the advantage that it doesn't require yet another language for something that really isn't used all that much on the SP, but might see more use in a proxy I think.
I agree that it's part of the larger conversation.
I do think the "automatic decoding based on encoding" idea may be a bit cleaner once we rethink the notion of encoding as an attribute resolver feature. If we think of a data dictionary as an N:N BiMap of some sort and ultimately probably implement aliasing of IdPAttributes...
TLDR: My suggestion would be to jettison this - for now- and then think about it in the round.
We used to have Issuer and Requestor. In V3 we just have Requestor (in the filter functions), in V4 it might make sense to reconsider Issuer as being someone who injects attributes to the IdP.
But I'm not sure if I want to take a step back and think this out some more. We also have attributes coming in from the Metadata, so that might (should?) be another dimension on all these filters.
Then there is the vexed idea of how attributes are represented. At least in theory we only deal with IdP Attributes - but that frayed somewhat for the Metadata Attributes.
I'm guessing that most gateways just shovel the attribute one, but it would be nicely cute if a proxy decoded the incoming attribute into an IdPAttribute which was then encoded. That way it would be a protocol bridge as well as a gateway. But I suspect that we would need to rethink the whole decoding thing. Currently decoding is driven from out encoders, which kinda makes sense for Metadata, but less so for a gateway. But if we formalized the encoding to be "encode/decode" and made it much more RP driven (as per Scott's desire to maximise metadata as the way to do configuration) then a standard encoding would be "Here's and attribute, this encoding works for this SP, have it". But a standard decoding could use exactly the same configuration : "Here's a (SAML1/OAUTH) attribute this decoding work for this IdP, have at it.
But just because you can make something look like something doesn't mean you should. My instinct has alwasy been that this is true for the SP using the IDP Attribute filtering language, which gets us exactly back to where we started.
(As an aside In the SAML protocols, delegation raises it's head and I have no idea what that looks like)
Either way, it does strike me that we might need to take a step back and think about attribute sources, attribute decoding and attribute encoding for V4. Which I had thought we might be able to avoid.
Bottom line, for V4 we should strip this particular nonsense out from the schema (it was never in the code). But we also need to think about attributes
It'll be relevant for proxying, so probably will get implemented at some point, or we'll come up with a different approach to filtering inbound.
It is a bit of a mind#^%$$ but I suspect the filtering engine will already work for inbound filtering just like it did in the SP. It's just a matter of directionally setting the requester/issuer fields.
In a moment of madness (or more likely oversight) this got pulled into the flattened schema despaite there never having been a parser for it.
Also note AttributeValueMatchesShibMDScope
I see no evidence that this filter has ever been implemented either in IdP2 or IdP3.
Since this is shared language with the SP I am guessing that the SP has this (I know it has the functionality, I didn't realize it could be configured like this).
I suggest that, for the IdP we either implement it or remove it (where the latter means remove from the documentation and annotate the schema that this is SP only.
Failing that, we should implement it, but that feels weird.