Entity Attribute Data Connector

[Cantor, Scott]

> 1) After some thought I think that the
> "urn:mace:shibboleth:2.0:attribute-map" namespace
> (shibboleth-2-attribute-map.xsd) schema is probably rather more than we
> want or need, and indeed has a lot of stuff which have no meaning to us ("Flag
> controlling whether the resulting attribute should be exported for CGI
> use").

I'm sure not all of it is relevant, but if you're talking about decoding SAML attributes into internal ones, that's mostly what it does, and most of it is going to be relevant.

That said, I'm not sure I'd call that a Data Connector exactly, although I suppose one use case for that would be if a user's credentials included a SAML assertion and you wanted to use that to populate subsequent attributes.

> 2) It makes sense to not limit this functionality to Entity Attributes, but
> rather to inject a navigation Function which takes an attribute resolution
> context and returns an XMLObject.  That way this connector can be used
> elsewhere.  Are there any flows in which an <Attribute/> might be
> presented  in the request and the Attribute Resolution might want to know about it?

Indirectly, maybe. It's more likely you'd want to have a data connector that could pull in data from the servlet request headers or attributes. Those wouldn't be SAML.

> 3) I think that for now we can ignore SAML1 Attributes, but we probably
> want to structure things to allow that to be added.  The idea that anyone might
> want to attach SAML1 attributes to SAML2 metadata does leave me
> bemused...

You can't have them in an EntityAttributes extension, but I don't think the EntityAttributes case really lends itself to a data connector. I don't know, maybe if you think about using a very stripped down resolver config as a second instance of the resolver to process EntityAttributes in metadata for use within the filter engine.

> 4) In general the dataConnector can be auto-sensing since the attribute
> carries type information.

That's really something the IdP does, over my objections. SAML strongly advises against typing attributes, the type should be based on the attribute name. Thus the attribute-map, which binds type (via Decoders) to names.

> You can see this in the AttributeConnector which
> used by the test code for idp-attribute-resolver.  My contention is
> (particularly for 3.0) it is sufficient to generate a StringAttributeValue,
> an XMLObjectAttributeValue, or nothing.

For EntityAttributes, I think that is true, but I think it should be handled by pluggable Decoders, not by baking in type awareness.

-- Scott