Populate signature validation parameters in SecurityParametersContext from peer metadata

[Brent Putman]

On 1/25/19 7:09 AM, Anshul Sirur wrote:
> Sorry, I should have specified that the 'senderMetadata' mostly wraps
> a MetadataResolver and MetadataCredentialResolver. There are multiple
> IDPs (and their signing certificates) contained within one metadata
> source.


That's fine then. Seems that it also includes a SignatureTrustEngine
(which if the ExplicitKey- type probably wraps the same
MetadataCredentialResolver). That is essentially what I would call
"configuration".


>
> My hope was that once the SAMLMetadataContext has been populated by
> the SAMLMetadataLookupHandler, tying the message to one of the IDPs,
> the credential for signature validation could be obtained from the
> RoleDescriptor in the SAMLMetadataContext. It didn't make sense to
> have to deal with resolving the RoleDescriptor in multiple places.


Technically you're correct in that, if you look closely at the details
of the SAMLProtocolMessageXMLSignatureSecurityHandler, the way it
builds its CriteriaSet for the trust engine is with
entityID+protocol+role.  In the case of the
ExplicitKeySignatureTrustEngine impl, it's passing that to its trusted
CredentialResolver to obtain the RP creds used for signature validation.

So yes, in the case of metadata-based collaborating component
implementations, it's in some fashion re-resolving the RoleDescriptor.
The reason it does that vs supplying RoleDescriptorCriterion is that in
general it doesn't know what kind of TrustEngine or supporting
components are involved, so it does the lowest common denominator that
will work for everything. (And note that *you* don't have to deal with
resolving RoleDescriptors in multiple places, that's all internal to
say the MetadataCredentialResolver,
MetadataPKIXValidationInformationResolver, etc.)

The overhead of doing that however is very minimal, as most of this
stuff is indexed so it's really just O(1) lookups against Maps, etc. 
There's also Credential caching going on in the
MetadataCredentialResolver.  So I really doubt that this constitutes
any significant performance overhead.

However, if it really bothers you, and you know that you're using
metadata-based components, you could extend
SAMLProtocolMessageXMLSignatureSecurityHandler and override
buildCriteriaSet(...) to add a RoleDescriptorCriterion, so
metadata-based components which understand that would use directly. 
Arguably we could add that additional Criterion now, as an
optimization, but as I said, there's really not a whole lot to optimize.


> So it seems to me that to obtain a -Configuration from the
> RoleDescriptor requires something like the following:
>
> SAMLMetadataContext -> RoleDescriptor -> Credential ->
> CollectionCredentialResolver -> ExplicitKeySignatureTrustEngine ->
> BasicSignatureValidationConfiguration


There is absolutely no need to do that.  That's way more complicated
than what is required.  The design is such that you really shouldn't be
creating -Configuration instances on-the-fly dynamically at runtime. 
-Configurations are things you create once, usually at startup/init
time.  Nor would you need to create on-the-fly credential resolvers or
trust engines. 

You definitely don't want to "obtain a -Configuration from the
RoleDescriptor".  That's just misguided.  You create one or more
-Configurations once.  At runtime you then evaluate -Configuration(s)
with a -Resolver to produce a -Parameters.


> This would happen in a LookupFunction similar to the one linked in
> Shib IdP.
>

No, it really doesn't do anything like that chain above.  All the Shib
IdP function is doing is looking up the appropriate pre-existing
-Configuration beans and returning them in a precedence order.  It is
not constructing anything new.  It's just "configuration lookup".  For
this particular case of signature validation, it's essentially just
determining "which (of possibly many) pre-existing declared
SignatureTrustEngine do I use for this particular relying party?" (as
well as determining any white-/blacklist algo overrides for that RP). 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190125/75ae8746/attachment.html>