Entity Attribute Data Connector

[Rod Widdowson]

Entity Attribute Data Connectors

I have been looking at these in odd moments this week and these are the
conclusions I have tentatively come to:

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

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?

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


4) In general the dataConnector can be auto-sensing since the attribute
carries type information. 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.

5) If needed we can easily add support for scoped attributes (of both types)
and also support for Binary data, and we probably need to bear that in mind
when we work out how to configure this.

6) This really just leaves the only configuration to be the navigation
function and code to handle attribute renaming and selection.

But I'm willing to be argued out of any of these conclusions.

Rod