RequestedAttributes and EntityAttributes

[Cantor, Scott]

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

They are somewhat overlapping but not really, it just happens that they
need the same core machinery to decode.

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

They're dealt with, but I believe only in raw, not decoded, form. That's
what I'm hoping to fix this summer.

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

Right, also currently implemented as brute force without being decoded.

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

That's fine, it's largely the same as the RequestedAttributes case anyway.

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

Clearly. Worst case it should only happen when evaluating such a rule, but
even that is pretty brutal to do over and over.

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

Yes, but the SP has similar problems. When you change attribute machinery,
that has serious risks of consistency problems, and that's just how it
goes. The best way to handle that is probably with warnings, and possibly
by disabling reload of those components by default.

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

That's all we can do. Most software doesn't even attempt to make this kind
of thing real-time.

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

We may want to optimize that by extending the SAMLMetadataContext to carry
the effective ACS entry, and we can populate that in an action in the SSO
profile flows since you have to pull from the AuthnRequest to determine
it. That's very simple to add, and it's even possible to go beyond the
spec I suppose, and populate this during queries if we assume the default.

-- Scott