Entity Attribute Data Connector

[Cantor, Scott]

On 5/13/13 9:07 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>>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?

I think it's too much overhead. Running the resolver every time you
process a piece of metadata for the filter engine seems like too much
work. The resolver would have connectors for all the user attributes and
those would run every time.

But a dedicated resolver configuration that was just configured to process
the EntityAttributes extension (and do whatever odd post-processing one
might care to do, I suppoe) probably is a decent reuse of the existing
code vs. creating some kind of dedicated abstraction like I did in the SP.
If I had it over again, I probably would have modeled the Extractor idea
differently.

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

Adding perhaps a pure XMLObject decoder would be about the extent of it,
and even that's stretching it.

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

We don't have to bound the discussion, but we can talk earlier in the week
too.

-- Scott