<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 1/25/19 7:09 AM, Anshul Sirur wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF_Anx+2=ZJjgZLWnR0cYFvgg4c2yF2tr98SDSitHNiv4sR=ww@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</blockquote>
<p><br>
</p>
<p>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".<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAF_Anx+2=ZJjgZLWnR0cYFvgg4c2yF2tr98SDSitHNiv4sR=ww@mail.gmail.com">
<div dir="ltr">
<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.</div>
</div>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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.)<br>
</p>
<p>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.</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAF_Anx+2=ZJjgZLWnR0cYFvgg4c2yF2tr98SDSitHNiv4sR=ww@mail.gmail.com">
<div dir="ltr">
<div> 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>
</blockquote>
<p><br>
</p>
<p>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. <br>
</p>
<p>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.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:CAF_Anx+2=ZJjgZLWnR0cYFvgg4c2yF2tr98SDSitHNiv4sR=ww@mail.gmail.com">
<div dir="ltr">
<div>This would happen in a LookupFunction similar to the one
linked in Shib IdP.<br>
</div>
</div>
<br>
</blockquote>
<p><br>
</p>
<p>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). <br>
</p>
<p><br>
</p>
<p><br>
</p>
<br>
</body>
</html>