Metadata Merge Facility

[Schwoerer, Brad]

Marvin,

Have you solved this yet.  It is something I would like to do as well.  My only hacking type solution would be to create a script that downloads and verifies the metadata, then does an XSLT on it to merge to files.  Sign that merged filed and use that as loaded file.

As Scott says as we get to dynamic metadata that beast changes.

-Bradley



On 7/18/17, 8:42 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

    On 7/18/17, 4:56 PM, "users on behalf of Marvin Addison" <users-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
    
    > That configuration is in metadata-providers.xml, which isn't subject to the hot reload facility that we have grown to love in IdPv3. > Besides, it defeats the strategy of moving the most common configuration points solely into metadata.
    
    Well, when you say "not subject to", that's slightly overstated. I admit it's perhaps inconvenient due to the size of, say, the full InCommon aggregate, to make metadata-providers.xml reloadable, but this is sort of a temporary problem. Once this gets converted to Dynamic, that wouldn't really add much reload overhead.
    
    That said, I have during my copious free time looked at various aspects of the filtering issue and thought about different ways of dealing with making it more dynamic. That was actually the reason I "wasted" a bunch of time architecting a way to make Spring beans reloadable on a per-bean basis using some crazy tricks. I haven't really put it into practice, but it did kind of work.
    
    > What I'd like to do is define stub metadata entries that have the needed attributes in a metadata source I control and have it 
    > merged with the canonical entry from another source. I guess you'd need a couple of different merge strategies (append and 
    > replace at a minimum), but it seems like it would solve my problem in a way that preserves the operational goal of being entirely
    > metadata driven. Is that a good idea? Have I missed an obvious alternative solution that's available today?
    
    We have pretty much completely avoided any kind of merging due to the general complexity involved. I'm sure it's possible to work out something on a very specific basis, but my feeling was that it was better to just come up with a way to make the filter configs more agile.
    
    -- Scott
    
    
    -- 
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net