<div dir="ltr"><div>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.<br></div><div><br></div><div>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:</div><div><br></div><div>SAMLMetadataContext -> RoleDescriptor -> Credential -> CollectionCredentialResolver -> ExplicitKeySignatureTrustEngine -> BasicSignatureValidationConfiguration<br></div><div><br></div><div>This would happen in a LookupFunction similar to the one linked in Shib IdP.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 25 Jan 2019 at 00:30, Brent Putman <<a href="mailto:putmanb@georgetown.edu">putmanb@georgetown.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p><br>
</p>
<div class="gmail-m_8983291118704369727moz-cite-prefix">On 1/24/19 11:55 AM, Anshul Sirur
wrote:<br>
</div>
<blockquote type="cite">
<pre class="gmail-m_8983291118704369727moz-quote-pre">Is it possible/recommended to populate the
SignatureValidationParameters of a SecurityParametersContext using the
SAMLMetadataContext+SAMLPeerEntityContext? </pre>
</blockquote>
<p><br>
</p>
<p>Not quite sure exactly what you mean by that, but I'd say no, at
least not literally, or directly. Maybe indirectly. See below.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<pre class="gmail-m_8983291118704369727moz-quote-pre">I want to validate the signature of a SAML
Response using a SAMLProtocolMessageXMLSignatureSecurityHandler. </pre>
</blockquote>
<p><br>
</p>
<p>Yes, and populating the context tree with
PopulateSignatureValidationParametersHandler is one correct way to
do that.</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<pre class="gmail-m_8983291118704369727moz-quote-pre">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 </pre>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.)
<br>
</p>
<p><br>
</p>
<blockquote type="cite">
<pre class="gmail-m_8983291118704369727moz-quote-pre">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.</pre>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p><a class="gmail-m_8983291118704369727moz-txt-link-freetext" href="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" target="_blank">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</a></p>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p>
</p>
<blockquote type="cite"></blockquote>
</div>
-- <br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank">dev-unsubscribe@shibboleth.net</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="color:rgb(0,0,0)"><font size="2"><span style="color:rgb(255,255,255)">--</span><b><br>Anshul Sirur</b><br>Senior Developer, <a href="http://GOV.UK" target="_blank">GOV.UK</a> Verify<br></font></span></div><span style="color:rgb(0,0,0)"><font size="2">Government Digital Service<br><br><img src="https://docs.google.com/uc?export=download&id=17UdIqvhbqr1Tvwk36wjFMDEm6i0m5lon&revid=0B37ZXPXUAdzRY3IvWm96VUpmdmtuQS8zQ0RsQ0JJMk94WWg4PQ" width="200" height="68"><br></font></span></div></div></div></div>