RequestedAttributes and EntityAttributes

[Cantor, Scott]

On 6/10/14, 1:23 PM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>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)

Right.

>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().

That's up to the IdPAttributeValue type, but the main thing I was
concerned about was scoped.

>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?

They both need the same comparison logic, and ideally that should be done
by asking two IdPAttributeValue subtypes to compare themselves. Then it's
extensible and it's entirely up to the value subclasses how to do that.
What I'm after is getting the design to hand that job off to the value
objects so that it's not inside the rules.

>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).

I would not be inclined to put them there, I'd pull them from the metadata
context as needed/if needed.

>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.

Ok. My opinion is that we shouldn't be expressing them there. I think it's
the filter function's job to get them from the metadata. But putting them
into ObjectMetadata means we can optimize all the decoding work, so the
function just has to access the metadata context and see if the objects
are there.

No need to complicate the FilterContext that I can see, and then we don't
have collisions between different sets and kinds of IdPAttribute
collections.

> 
>MetadataReload:  SAML Attributes (of some sort) -> IdPAttributes, stored
>in
>the ACS.
>SSOProfile: IdPAttributes from the ACS-> the SAMLMetadataContext

No, the ACS itself -> 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.

Right, so it's the functor itself that accesses the metadata context,
checks for an ACS and in turn for the attached IdPAttributes.

Same for the EntityAttributes case, except that's hung as ObjectMetadata
off the EntityDescriptor.

-- Scott