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

[Cantor, Scott]

On 5/30/14, 8:08 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Didn't we want in v3 to avoid using explicit references to
>EntitiesDescriptors as a concept?  And in terms of implementation, use
>the new object metadata EntitiesDescriptorGroupName, rather than coding
>to looking at EntitiesDescriptors?

I remember discussing something else, I didn't go looking for it. I was
more concerned about configuring this than implementing it, I just needed
something to test with.

The filter implementation was done a while ago, I was just adding some
error checking.

>For the impl, we'd need to declare the NodeProcessingMetadataFilter, with
>the desired MetadataNodeProcessors, e.g. EntitiesDescriptorNameProcessor.
> (We need to do that anyway for the KeyAuthorityNodeProcessor, otherwise
>the legacy PKIX trust engine stuff won't
> work.   Unless we make that support optional, commented out, etc.)

I don't think either Rod nor myself are familiar with that code so it's
not currently part of the configuration logic. We would presumably have to
bake this into the default metadata configuration parsing code, because if
the group policy implementations relied on it, they'd have to be installed
without the user actually putting them in, since they're not in the V2
configuration now.

>Walking the tree for the EntitiesDescriptors as below does currently
>work, because the metadata resolvers don't currently destroy or mutate
>the tree structure.  But with our new EntityDescriptor-centric focus,
>that's not guaranteed to always be the case - unless we decide that
>preserving it is a requirement, but that would be moving in the opposite
>direction from what I thought we wanted.

Preserving the functionality is a requirement, but if we're going to do it
a different way, we probably need an issue to track that.

Is the code for these new filters complete?

-- Scott