Parsing Trust Engines

[Rod Widdowson]

Just to tie this off.  

I realised over night that even unsupported elements required a parser for
the Alpha - otherwise V2 legacy relying party files would not load and that
would destroy a lot of the value of getting any legacy relying-party.xml
working.

This required a certain amount of finessing in the parsing for
ChainingSignature engine since some of its children might not be of a
supported type.   But I inserted a Factory bean to make this work (you
cannot detect this in the parser since children may be supplied by
reference).

Hence:

 - ChainingSignature and StaticExplicitKeySignature are implemented and
tested.  I don't expect that the former will ever be used but it will be in
legacy files and it *could* be used.

- StaticPKIXSignature parsing is present, but issues a warning (and will
probably need to be explicitly removed from configurations for the Alpha).

All the others issue a warning that they are being ignored.

Armed with this the test to parse the V2 default relying-party.xml now
passes.

R

> -----Original Message-----
> From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net] On
> Behalf Of Brent Putman
> Sent: 20 June 2014 17:58
> To: dev at shibboleth.net
> Subject: Re: Parsing Trust Engines
> 
> 
> On 6/19/14 10:31 AM, Cantor, Scott wrote:
> > I'd defer to Brent, but in the SP, you have the use case in the Dynamic
> > provider of using transport authentication, and that's not a Signature
> > trust engine.
> >
> > I don't know if the code in the IdP for this is capable of using the
> > transport.
> 
> 
> >From the call: The answer is the dynamic metadata resolver code that's
> out there doesn't currently support this, but it's in a useable state
> anyway.  I'll put this into the Jira case for when I get back around to
> finishing out this resolver.
> 
> --
> To unsubscribe from this list send an email to
dev-unsubscribe at shibboleth.net