SAML attributes to IdP Attributes

[Rod Widdowson]

As background to today’s meeting, here is a summary of a Skype conversation
Scott and I had, suitably expanded as my understanding has grown.  

EntityAttributes

I had thought that this was the main use case.  We now believe (Scott always
did, I have been persuaded) that the existing V2 code for the 4 matchers is
sufficient, and that it really is overkill to make the Attributes in an
EntityAttribute into IdP Attributes, just so that they can be used in
filters.

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)

Because of the architecture of V2, the V2 code is pretty ugly.  Some of this
is because for every call to filter every value for every attribute which
has this filter on it, the logic has to iterate across the SSODescriptors to
find the correct ACS.

But most of the ugliness comes from the type mismatch.  We are looking at an
IdP Attribute, we are given a SAML attribute and we have to answer the
question “When this IdP attribute is encoded, by all specified encoders for
all protocols, will any of them look like SAML Attribute that I have been
given?”

In V3, the proposal is:

Add a stage prior to running the attribute filter engine which will convert
the SAML attributes from both these sources and populate the
AttributeFilterContext  with a map/list/set  of some representation of the
<RequestedAttribute/> or <Attribute>.  This obviates the need for both
iterations.

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

The flip side of this setup is that the new stage requires that we specify
the reverse mappings (name & type) from SAML to IdP.  Further the nature of
the encoders is such that a specific SAML name may give rise to multiple IdP
names (an encoder on multiple attributes) and an IdP name may map to
multiple SAML attributes.

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.

The next question is how to represent the reverse mapping.  Whilst this can
be constructed from the attribute-resolver.xml, this may well be overkill.
So the current plan is to explicitly represent the reverse mapping by way of
same syntax that the SP uses.  This raises the issue of inconsistency, but I
think I’d sooner deal with this (if we want to) with an explicit check that
the mapping does indeed reflect the contents of attribute-resolver.xml

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

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.

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

[*]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.   The two screw situations are when an attribute is
configured to encode multiple SAML2 attribute id/format pairs (which can be
configured against) 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.

Consider 
	Attribute A encodes to formats S,T
	Attribute B encodes formats S, U
	Attribute C encoded attribute S

Then if the constraint is
	S with values 1,2,3
	T with values a,b,c
	U with values x,y,z

Then the RequiredAttribute map will be
	A = {[1,2,3], [a,b,c]}
	B={[1,2,3], [x,y,z]}
	C ={[1,2,3]}

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

Rod