Entity Attribute Data Connector

[Rod Widdowson]

Just to close this off.  After some fights with browsers and Confluence,  I
have added a brief write up about this 

https://wiki.shibboleth.net/confluence/x/dYBX#AttributeFilteringEngine-Attri
buteInMetadataandAttributeInRequestnewinV3filters

Rod
> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net]
> On Behalf Of Cantor, Scott
> Sent: 13 May 2013 15:21
> To: Shib Dev
> Subject: Re: Entity Attribute Data Connector
> 
> 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
> 
> 
> 
> --
> To unsubscribe from this list send an email to dev-
> unsubscribe at shibboleth.net