Populate signature validation parameters in SecurityParametersContext from peer metadata

[Anshul Sirur]

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.

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. So it seems to
me that to obtain a -Configuration from the RoleDescriptor requires
something like the following:

SAMLMetadataContext -> RoleDescriptor -> Credential ->
CollectionCredentialResolver -> ExplicitKeySignatureTrustEngine ->
BasicSignatureValidationConfiguration

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

On Fri, 25 Jan 2019 at 00:30, Brent Putman <putmanb at georgetown.edu> wrote:

>
> 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.
>
>
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net



-- 
--
*Anshul Sirur*
Senior Developer, GOV.UK Verify
Government Digital Service
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190125/c7f01471/attachment-0001.html>