Entity Attribute Data Connector

[Rod Widdowson]

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

I'm not sure I totally follow you (yet).  I (now) totally get it that the
AttributeType and its concrete implementation is critical, particularly
given that we need to make the type-management explicit.
Rather than discuss it here it will probably be easiest to just take a few
minutes from Friday's meeting to put this one to bed.  For now this "just"
configuration, and all I need to do is make sure that any data connector
built can be described this way.

> [...] You can't have them [SAML1 atributes] in an EntityAttributes
extension, but I don't 
> think the EntityAttributes case really lends itself to a data connector. 

Again I'm, not sure I completely follow.

I'm thinking of a connector which takes a Collection<XMLObject> (where
initially XMLObject would be expected to be a SAML1 or a SAML2 Attribute).
This obviously does not match an EntityAttribute definition, and in
particular I need to understand and we need to decide precisely what we do
with the Assertion statements it can hold: I'm guessing that it does not do
to just flatten out the assertions it contains.  However I am inclined to
view that as a different issue and to punt it to different functionality,
configured separately, and for now concentrate on just the format conversion
(SAML1/2 to IdP).

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

That had been my intention/understanding.  I'm not sure that it needs to be
a separate resolver - so long as the names are kept distinct an attribute is
an attribute is an attribute and we shouldn't care whether it is the input
to a script or to a filter or something to release to the SP...  Or have I
missed something?

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

I hear you.  That in itself casts a different light on the
usefulness/importance of the attribute map schema.

I kicked this around over the weekend and it has proven to be pretty simple
to create something which is specifically useful (for EntityAttributes) and
generally applicable.  Given the framework it was trivial to add decoders
for Scoped and XMLAttribute, and the question then becomes where to stop.

I'll play with this some more during this week, I'd like to take a max of 5
minutes to chat on Friday with a view to checking in the 2 Dataconnectors
(SAML1/2) and 4 XMLAttrributeMappers (String, ScopedString, XMLObject,
Base64String) next weekend.

Rod