Parsing the trust engines

[Cantor, Scott]

On 4/23/14, 8:09 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>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.

Yeah, the part that never fit with me was that the stuff that consumes
trust engines at the time mostly all lived in relying-party.xml, and it
wasn't obvious to me how things would end up.

I suppose I can see this now, but I'm still unable to see how we would
rationally make them part of a parent context to two separate Spring
contexts being managed as these services themselves. I think it breaks
down because we ended up redoing the V2 service model and carrying that
forward to solve the locking issues in a way that Rod and I were
comfortable with.

So yeah, I think we need a Service.

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

The basic answer is Rod has that (or will have, maybe it's not done yet)
defined as a Service, and we'll inject them like we do today with the
AttributeResolver, which is also a Service. The Service abstraction is
basically the proxy idea more or less since it involves something you lock
and unlock around using the thing inside it.

The thing you inject is ReloadableService<T> where T is the actual thing
we're using.

I don't know that Rod is clear on the Role vs. Entity distinction in the
new API, though, he'd have to speak to that. The Service probably needs to
expose both options, or if it can't do that, we'll have to figure out what
to do there.

I don't think anything here is circular in general, the metadata verifying
trust engines wouldn't in general themselves take metadata-based trust
engines. I guess you could argue that they could in theory in some twisted
way.

-- Scott