Signature validation filter config

[Brent Putman]

On 4/14/14 1:44 PM, Cantor, Scott wrote:
> On 4/14/14, 1:14 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>> I can think of at least 2 use cases where the user would want or need to
>> wire in multiple validation certs/keys: 1)  for the dynamic metadata
>> resolvers(s), where you really do have multiple concurrent trust
>> material
> The problem with (1) is that you lose naming constraints. Without a more
> complex algorithm, the single key would be usable to vouch for any query
> result, and that's not really what you want, necessarily, so my guess is
> we'll need something more than just listing certificates anyway.


Yes.  There's already a TODO (really just a lengthy note) in the filter
for exactly this kind of thing, which we deferred in v2 since we didn't
have a dynamic provider or support any other complex cases.  It's
basically all about how you build the CriteriaSet that you pass into the
TrustEngine.  One off-the-cuff idea is to support an injectable strategy
for building the criteria set.

In some quick thinking about it:  this wouldn't really work with the
cert/key file passed as an attribute anyway.  You (probably) need the
entityID and/or key names associated with the credential, to support
resolving only the Credential(s) which are applicable, which would in
turn mean you need to have a full Credential bean declared so you can
specify those additional properties.  There's more to a Credential than
just the key...  Although if you *are* actually using a cert and not
just a public key, I suppose one possibly strategy is to map the
entityID of the metadata being processed to some info represented within
the acceptable validation cert(s), so that you can construct the
appropriate criteria such that only those get resolved and considered by
the trust engine's CredentialResolver.


>
>> If we do go with the attributes option, should we consider making those
>> XML delimited lists of certs/keys?  Maybe that's too complicated...
> It would be less so if we could resolve relative paths like the SP does,
> and just find credentials in idp/conf/creds/

Yes, that would be nice.