Parsing the trust engines

[Cantor, Scott]

On 4/22/14, 9:42 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>Thus it seems to me that the only sensible use of a <sec:TrustEngine>
>inside
>relying-party.xml is as (legacy) input to <metadata:SignatureValidation>.

Yeah, unless we build a service around the trust engines I guess, so we
can get at them in those message handler beans and actions. From a
compatibility standpoint, there's not much point to that because the
current config that would have overridden the runtime trust handling was
those policy rules, and if we don't support those, there's no
compatibility with having made such changes anyway.

>Unfortunately it doesn't mean that I don't have to be able to parse all
>variants since I'm guessing that it's perfectly acceptable to have
>arbitrarily complex trust engines associated with a metadata filter.

Yeah, I think so.

>OTOH if we do want to define all trust engines inside relying-party.xml
>then
>it should not be too difficult to teach the beans inside
>security-beans.xml
>to lookup up trust engines via a Service.  However I will note that in V2
>these trust engines are all contained below the <!-- DO NOT EDIT BELOW
>THIS
>POINT --> mark.

Yeah, see above. I think it doesn't really buy us anything but we do have
to settle on where to put those trust engine beans as consumed by the
security handler beans in terms of what people would be able to change
safely.

My inclination is that we'll do it with native Spring in a user-space file
that wouldn't generally get touched, but could in edge cases, and we'll
feed a fixed bean ID into the handlers. The handler beans in
security-beans.xml are meant to be hands off because if you want to
customize that, you'd override the subflow being invoked and be
responsible for your own beans (by copying from that file probably).

A lot of the final names and locations on the security policy flows is
TBD, I just wanted to get it working over the weekend.

-- Scott