RequestedAttributes and EntityAttributes

[Rod Widdowson]

Scott and I have been chatting about Attribute Mapping and the alpha.

I managed to get myself confused while swapping this stuff back in and I
have a few questions arising from this, so I wanted to widen the
conversation.

To start with I want to explicitly distinguish RequestedAttribute (which
most of the rest of this mail is about) from EntityAttributes.  I confused
these in my mind and may have been mis-communicating.  So part of this mail
is to clear up my confusion.

EntityAttributes are defined in sstc-metadata-attr and, as far as filtering
is concerned, are largely dealt with already by the
"saml:AttributeRequesterEntityAttributeXXXMatch" filters.

This mail is about the <RequestedAttribute/> statements (as defined in
saml-metadata-2.0-os) which we can find inside the AttributeConsumingService
inside the SPSSODescriptor.  The filter of interest for these attributes is
of type "saml:AttributeInMetadata"

For completeness, there is also the capability to put an <Attribute/> inside
an <AttributeQuery/> (as per saml-core-2.0-os).  But I'd like to leave this,
and any potential filters, as out of scope for now.

We decided that the sensible way of treating Requested Attributes in V3 was
to map the (SAML) RequestedAttributes into an IdP Specific homologue and
then filter by comparing like with like.  This is in contrast with the V2
filter which does on-the-fly conversion during the filtering process.

We did all this work some time ago and the time has come to plumb it all in.

I have had two concerns about this plumbing.

1) That we should try to avoid the cost of mining the metadata for
RequestedAttributes as part of each request (particularly since the majority
of requests will not need the information).

2) That there is a timing window between converting the (SAML)
RequestedAttributes into their IdP homologues and the generation of the IdP
Attributes.  During this window the Attribute encoding may have changed and
were we to apply the conversion process again we would get different
results.

Scott made the suggestion that we could in fact do the conversion as a
NodeProcessingMetadataFilter and attach the IdP RequestedAttributes as
metadata [somewhere] to the Entity Metadata.  This is very appealing - it is
a natural fit for the ObjectMetadata stuff that Brent added and it very
neatly deals with my issue (1) above.  But it does significantly widen the
timing window associated with (2).

So my first question is whether we are concerned enough about this timing
window and if so what we should do about it? Documentation would be my
preference.

Moving on, at 100,000 feet the mechanics of this look very simple.  On
metadata load we attach the mapped attributes and during the flow we pluck
them out, plug them into the FilterContext and we are done.

But it leads to my second question, what is the correct place to store these
mapped Attributes?  On the SAML side they are part of the ACS and so storing
them there makes sense.  But when we come to the FilterAttributes action
(when we need to store them in the FilterContext) we only have the Role and
the EntityDescriptor.  In V2 we iterate over all the ACS until we find a
match (positive or negative).  Is the V3 equivalent of this (whatever that
exactly is) sufficient?

Thanks

Rod