RequestedAttributes and EntityAttributes

[Rod Widdowson]

> They're dealt with, but I believe only in raw, not decoded, form. That's
> what I'm hoping to fix this summer.

That’s what I have been missing.   The V2 filters (which we have ported
pretty much unchanged) are very simplistic - they just look for a string (in
some guise) in an AttributeValue.    There's nothing too brute force since
there is no decoding involved - just string comparison (on raw data)

The rawness will therefore would only bite us for things like scoped
attributes and XMLObjects and the latter worries me anyway because I'm not
sure that we are at all certain what #equals() means for an XMLObject().

Are we saying that we need more than this?  If so what are the semantics
that we need?  Is it something like the AttributeInMetadataPolicyRule,
(where we are comparing attribute with attribute, not attributeValue with
String) only for EntityAttributes?

Once I grock what the filter is, the extra code + plumbing is easy to do, we
mostly just need a wee bit more mechanism.   We probably also need an extra
slot in the FilterContext for these IdPAttributes (to distinguish them from
the IdPRequestedAttributes).

>> The filter of interest for these attributes is
>> of type "saml:AttributeInMetadata"
> Right, also currently implemented as brute force without being decoded.

No, as it currently exists that filter requires that there be
IdPRequestedAttributes present in the AttributeFilterContext.  My assumption
thus far had therefore been that it was plugging these in that was the
issue.
 
> Yes, but the SP has similar problems. When you change attribute machinery,
> that has serious risks of consistency problems, and that's just how it
> goes. The best way to handle that is probably with warnings, and possibly
> by disabling reload of those components by default.

Good.  Thanks.

> We may want to optimize that by extending the SAMLMetadataContext to carry
> the effective ACS entry, and we can populate that in an action in the SSO
> profile flows since you have to pull from the AuthnRequest to determine
> it. That's very simple to add, and it's even possible to go beyond the
> spec I suppose, and populate this during queries if we assume the default.

That would be useful, so the flow is something like

MetadataReload:  SAML Attributes (of some sort) -> IdPAttributes, stored in
the ACS.
SSPProfile: IdPAttributes from the ACS-> the SAMLMetadataContext
FilterAttributes:  IdPAttributes from SAMLMetadataContext->FilterContext.
In fact this step isn't needed since the FilterContext already carries a
Function to get from itself to the SAMLMetadataContext.

/Rod