SAML attributes to IdP Attributes

[Cantor, Scott]

> AttributeInMetadata and AttributeInAttributeQuery
> 
> These two cases (the first supported in V2, the second not) are the same,
> the only difference being where the <Attribute/> (or
> <RequestedAttribute/>)
> statements come from (the ACS or the AttributeQuery)

They're close, but I'm not sure they're identical, because the query filtering is technically mandatory for any query implementation, but the metadata thing is not, it's advisory.

But I suppose in practice no matter how it's done it will end up as a block of code one could easily disable via configuration and end up with non-conformant queries, so where the code is doesn't matter that much.

> The AttributeInMetadata filter (which probably needs to be renamed to
> AttributeIsRequested to reflect the dual source), then just has to work with
> IdP Attributes and IdP AttributeValues (and by extension becomes transport
> neutral).

They may need to be two different things so that one could turn off the metadata feature without having to render one's queries non-conformant.

> This raises the first of a few open issues/questions:  the structure
> representing the reverse mapping cannot be a simple Map, or a Set.  I think
> that the correct structure is a Map<String,Set<Attribute>> where the key is
> the Internal  Attribute ID, and the value is all the populated attributes of
> that name.  See [*] below.

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. I assume we have multimaps available so you don't have to implement a map to a set.

> We also have to deal with the isRequired attribute.  It is probably best to
> do this by inheriting RequestedAttribute from Attribute with the addition of
> an isRequired boolean (which is always true if the attribute came from the
> AttributeQuery?)

Hadn't thought of that, but no, it's not the same. "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.

> This segues onto the next question which is whether this work really can do
> both jobs (Metadata and Request), and what happens if there is a conflict
> (when the ACS and the AttributeQuery specify the same attribute, but the
> values differ).  I'd assume that AttributeQuery trumps ACS.

They don't apply in the same flows, so don't conflict.

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

> [*]And finally I spent some time considering whether there are edge cases
> which might do unexpected things.  The answer is yes, but they are very
> weird, can be configured against (I think), and otherwise would result in
> illegal Assertions.

I'll probably need some concrete examples here, but I think some of your edge cases are to be expected and handled somehow.

>  The two screw situations are when an attribute is
> configured to encode multiple SAML2 attribute id/format pairs (which can be
> configured against)

No, that's a legitimate use case. Or at least, it would be in existing resolvers today and for us to make it illegal would cause some pain.

> and when multiple attributes encode to the same type and
> both attributes will survive the filter which cannot be configured against,
> but which unless done with knowledge of the attribute values will result in
> an invalid Assertion.

I don't follow that case.

> "It can be seen" that oddness could occur (for instance SAML attribute S
> will be constrained to valued specified in SAML Attribute T although there
> are many other cases).  AFAICS, all cases either can be fixed by deriving
> subsidiary attributes such that each only one encodes one SAML2 format or
> would only occur if the filter policies were such that two attributes which
> encode the same format are active for release.  This is at the least odd and
> at the most, illegal.  So I do not think we need to worry about these cases.

I think a concrete example would help. I think problems exist and will need to be handled some consistent way, but I don't know what they are yet.

I do think the onus is on the dictionary process to know that if you have ID foo encoding to SAML names bar and baz that both bar and baz reverse map and decode to foo.

A more wacky resolver handling broken SPs and such by aliasing attributes is going to require more care, but since those wacky cases almost never coincide with query or metadata use cases, I doubt the impact will be high.

-- Scott