Populate signature validation parameters in SecurityParametersContext from peer metadata

[Brent Putman]

On 1/24/19 11:55 AM, Anshul Sirur wrote:
> Is it possible/recommended to populate the
> SignatureValidationParameters of a SecurityParametersContext using the
> SAMLMetadataContext+SAMLPeerEntityContext? 


Not quite sure exactly what you mean by that, but I'd say no, at least
not literally, or directly. Maybe indirectly. See below.


> I want to validate the signature of a SAML
> Response using a SAMLProtocolMessageXMLSignatureSecurityHandler. 


Yes, and populating the context tree with
PopulateSignatureValidationParametersHandler is one correct way to do that.

Ultimately the signature validation handler doesn't care how the
-Parameters instance is populated into the tree.  Our main and preferred
approach is to take a precedence-ordered list of -Configuration
instances, process them by a -Resolver which produces an effective
-Parameters instance. That's what
PopulateSignatureValidationParametersHandler does.  You'll see the same
pattern of components for other security cases, like signing, encryption
and decryption.


>
> 16
> 17    // *** Is there a better way of doing this? ***
> 18    signatureValidationParametersHandler.setConfigurationLookupStrategy(msgCtx
> -> {
> 19        SAMLMetadataContext metadataCtx =
> msgCtx.getSubcontext(SAMLMetadataContext.class);
> 20        BasicSignatureValidationConfiguration
> signatureValidationConfiguration =
> (BasicSignatureValidationConfiguration)
> ConfigurationService.get(SignatureValidationConfiguration.class);
> 21        signatureValidationConfiguration.setSignatureTrustEngine(senderMetadata.getSignatureTrustEngine());
> 22        return List.of(signatureValidationConfiguration);
> 23    });
> 24   


Well, don't do that.  At least, not if your 'senderMetadata' class is
specific to a particular SAML peer. (I can't tell since it's not
illustrated).  In that case then what you're doing is populating the
*global* instance of SignatureValiationConfiguration with data for a
specific peer.  In a multi-threaded web server environment, with
different peers, that's obviously not going to work.

If 'senderMetadata' is not specific to a particular peer (i.e. you
really have just 1 SignatureTrustEngine instance, for all peers), then
it works ok I guess, but it would probably make more sense to just
create the configuration object and config lookup strategy look just
once somewhere and reuse, rather than creating all those new objects on
every request in a lambda.

Also see below about layering multiple -Configuration instances
together.  Ideally you would not modify the library global
SignatureValidationConfiguration like that. Instead create a new
instance of your own, with your trust engine and other config, and then
return that and the global one from the lookup strategy.  (The main
purpose of the global one for signature validation is to provide library
defaults for algorithm whitelisting/blacklisting.)  


> There don't seem to be any Handlers in the current OS3 API that do the
> job of lines 19-22. Validating a message signature using the X509
> credential presented in the peer metadata seems like something that
> would happen frequently so this might be useful functionality to
> implement.


Correct. The only thing that isn't implemented in OpenSAML is the
configuration lookup strategy function.  That's because how you actual
resolve the SignatureValidationConfiguration instance(s) is highly
project specific.  (I think it's essentially in part what you are doing
with whatever 'senderMetadata' is).    It might be beans in an IoC type
of environment (e.g. Spring) or it might be classes instantiated based
on custom config files or property files etc.   So that's a piece that
the caller has to supply.

To see a real world example of that, see the impl of this strategy for
the Shibboleth IdP.  We have 3 layers of config 1) relying-party
specific 2) profile defaults 3) global defaults.  As I said above, the
-Resolver turns those into a single effective -Parameters instance.

http://git.shibboleth.net/view/?p=java-identity-provider.git;a=blob;f=idp-profile-api/src/main/java/net/shibboleth/idp/profile/config/navigate/messaging/SignatureValidationConfigurationLookupFunction.java;h=cda6e9995f50502b87c08caa7470f70e5a7d1f50;hb=refs/heads/maint-3.4


The config lookup strategy function isn't very complex, or at least
doesn't have to be. But it does depend entirely on how your project's
config is managed.  So you have to supply it.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190124/760b9012/attachment.html>