Parsing the trust engines

[Brent Putman]

On 4/22/14 11:29 AM, Cantor, Scott wrote:
> 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.


Sounds right to me.



>> 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.

Yes, I think so too.


>> 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.



I *think* this may be the "thing that Chad wanted to with splitting out
the security stuff to its own Spring (parent) context, and that none of
us can remember".  It was essentially about making TrustEngines visible
to things that were in v3 going to live in different layers.  I think
we've abandoned that idea.  If we need to support common access to the
same trust engine beans, etc, sounds like we indeed are leaning to a
Service model.



> 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).


Not having to repeat the config for that case would be nice, but if it's
too hard to support, then I suppose the duplication isn't really a big
deal.  But thinking to the next step/question:  all the trust engine
beans for the message handlers essentially have to get injected with a
MetadataCredentialResolver or MetadataPKIXValidationInformationResolver,
which in turn take either a MetadataResolver or a
RoleDescriptorResolver.  Where does that come from in the new layout,
and is that a problem?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140423/100d2f00/attachment-0001.html