HTTPResource and multiple Metadata Provider files

[Cantor, Scott]

> We are looking at doing something kinda similar to what Keith Wessel does
> with HTTPResource and attribute filters, but using metadata providers and
> metadata attribute filters instead (We found it to be more flexible)

Do you mean an entity attribute filter? And that isn't something you load remotely by itself, only resolvers can really be configured. Filters are attached to resolvers.

> We want to load InCommon metadata using various filters in the following
> order:
> 
> metadata-providers-local-override.xml
> metadata-providers-remote-uc-approved.xml
> metadata-providers.xml

I don't understand the reference to filters. There isn't any way to load filters indirectly, is there? Maybe that was something we did to support referencing a Spring bean as a filter? You could supply additional resources to the MetadataResolver service's config set, but those would contain actual MetadataResolvers, not filters. Filters are attached to resolvers, basically, so they're "inside" the thing you'd be loading with those resources.

> The first two files would need to whitelist the entities in which we want to
> add additional attributes, so we don't load the entire InCommon metadata
> three times.

Basically, you *are* loading the metadata three times unless I'm not following you. And you don't want that, so...

> But the last one would be the fall through that loads metadata in
> it's entirety. I'm finding that which ever file lists the metadata first will have
> it's attributes or lack of attributes as the metadata descriptor entry. Is this
> expected behavior?

Duplicate entities across metadata sources are resolved in order in which the resolvers appear, but I don't know what happens if you supply multiple files, that would potentially be a mess. In general, I think you can only safely count on the order within a single resource's MetadataResolvers. So you could hijack metadata for an entity from InCommon's feed with a local feed, but that's about as far as I would go with it.

But again, this is about resolvers, NOT filters. Filters run inside a resolver, never at the "top" across all resolvers.

> Also is the HTTPResource only available in IDP30?

It was possible, and constantly unreliable, to load HTTP resources into V2 services. I don't think it's substantially more reliable now. I wouldn't do it, and there's no security on it anyway. I would do it out of band, and rsync them over as files.

I realize many federations do this, and it remains, IMHO, a really bad idea.

-- Scott