SAML attributes to IdP Attributes

[Rod Widdowson]

To bring this thread up to date for the record, based on Friday's
discussion.

Firstly, I will (shortly, but not immediately) write up the design based on
this in the wiki.

For the rest:

> > The AttributeInMetadata filter (which probably needs to be renamed to
> > AttributeIsRequested to reflect the dual source), 

No.  As Scott says these are different things.  The design will cope with
this by keeping them separate and having separate filters.

> That's not so much the mapping structure as the result of the decoding?
> Meaning once you've decoded, you have a multimap from ID to Attribute
> since two SAML attributes could both decode into an Attribute with the
same
> internal name/ID. 

Right.

> I assume we have multimaps available so you don't have to
> implement a map to a set.

There's one in guava.

> "Required" in the metadata
> sense is different. With queries, you're not demanding that an attribute
be
> present, but that the result shouldn't contain anything that isn't in the
query.
> isRequired is about signaling SSO logic that if an attribute/value won't
be
> present, you can expect a bad outcome at the SP.

Thanks.  This is key.
 
> > We need to understand comparison of XMLObjectAttributeValue.  The
> spec
> > says
> > "In the absence of equality rules specified by particular profiles or
> > attributes, equality is defined as an identical XML representation of
the
> > value".  This doesn't really help.  I propose we just do the same as V2
> > currently does (I'll need to dig into what that actually means).
> 
> That's talking about SAML comparison. Here we've decoded back into
> something else, and so the decoding process produces something we should
> implement comparison against. In some sense that's the point of decoding,
> to produce something you control the syntax of.

Right.  So as discussed this punts to another area of the code (which I have
to worry about, but not here).  Tom suggested guava's equivalence, but it is
a steam hammer to crack a very small pea nut.

> > [*]And finally I spent some time considering whether there are edge
cases
[...]
> 
> I'll probably need some concrete examples here, but I think some of your
> edge cases are to be expected and handled somehow.

I was convinced that there were some, but once I write them down they
disappear as expected or GIGO.

Case 1:  Expected Oddness 

IdP Attribute A encodes to SAML attribute S & T
IdP Attribute A has the filter associated with it.

Request limit the values on S to be a & b.
A starts with values a,b,c,d.
After encoding both S & T only have two values (a&b) , despite T not having
any restrictions applied.

I think we can argue that this is expected;  anyway there is an obvious
mitigation.  This was all I meant in my previous mail, I am not proposing
making multiple encodings of the same attribute illegal, just that if
oddness occurs which you don't like (a) it is expected and (b) you can do
something about it.

Case 2: GIGO

IdP Attribute A encodes to SAML attribute S & T
IdP Attribute A has the filter associated with it.
IdP Attribute B encodes to SAML attribute S & U
IdP Attribute A does not have a filter associated with it.

Request limit the values on S to be a & b.
A starts with values a,b,c,d.
B starts with values 1,2,3

After filtering and encoding we see S with attribute values of
((a,b),(1,2,3)).  I'm not sure that this is a valid assertion, but I am sure
that in this case this is what should be expected; you should have filtered
B if you cared).

As far as I can see, all my other cases either fall into one of these two
cases, or cannot be constructed.

Rod