[java-identity-provider COMMIT] /trunk/idp-saml-impl/src/main/java/net/shibboleth/idp/saml/profile/logic/EntitiesDesc...

[Cantor, Scott]

On 5/31/14, 12:29 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>
>> 
>> We're sticking with the legacy config for Metadata right now, I think,
>>so
>> we probably need to define the schema for the new filter if it's not
>> onerous to define it.
>
>That's pretty easy to do.  Are there other metadata filters we need to
>define at the same time?

I don't think so. I knocked this out tonight, it was easy, *except* for
the auto-attach part.

I really don't see a great way to do that from within the Spring parser,
and this really seems like something a BeanPostProcessor is perfectly
suited for...post-process any MetadataResolver beans, and interrogate the
bean to find out if it's equipped with the filter or not.

I suspect there are other things you had to hack into the parsers that we
could use a post-processor for. The trick is, we need to expand the
SpringSupport methods to let us inject BeanPostProcessors into the
context, because it has to be done before refresh() gets called. No big
deal to do this.

>I have a mental note - and there may be a JIRA case as well to go back
>over the entities group things again (I cannot remember how we do the
>relyingparty entities group predicate right now, but the filter which
>dates back over a year is still old style).

Yes, that's what Brent is talking about. I built the predicate the old way
for now, but there is a note in the Jira case for the attribute filter
function about this. It's just not specific as to the issue, so I didn't
pick up on it.

>It sounds like I need to get onto this when I get back,

I'm screwing around in this area already, I'll probably have it done this
weekend or early next.

-- Scott