<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 8/21/15 7:53 PM, Brent Putman wrote:<br>
</div>
<blockquote cite="mid:55D7B9F2.6090003@georgetown.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 8/20/15 6:36 AM, Rod Widdowson
wrote:<br>
</div>
<blockquote
cite="mid:012f01d0db34$2474ef90$6d5eceb0$@steadingsoftware.com"
type="cite">
<pre wrap="">If this doesn't feels like a "RelyingParty" thing you can create a new interface to do what you need, make DefaultRelyingPartyConfigurationResolver implement it and then build your own service based around that. I have currently swapped the precise details out on how to do this, but it's how the AttributeResolverImpl masquerades as an Attribute Resolver and an Attribute Mapper.</pre>
</blockquote>
<br>
What I did for now, to keep moving forward, was just define a
List<Credential> directly on
DefaultRelyingPartyConfigurationResolver. Then a specialized
credential resolver injected with the service gets the serviceable
component on each call. It needs to check and cast to
DefaultRelyingPartyConfigurationResolver, so it uses the service
directly (shibboleth.RelyingPartyResolverService), rather than the
facade bean (shibboleth.RelyingPartyConfigurationResolver). At
least until we decide whether we want to promote this to the
RelyingPartyConfigurationResolver interface.<br>
<br>
This turned out to be pretty easy.<br>
</blockquote>
<br>
<br>
FYI, in looking at the delegation NameID encryption stuff (the need
to encrypt to self) I realized that we pretty much need the same
thing for the IdP's encryption creds. So I just copied exactly what
I described above for the signing creds. I.e. it's all impl at this
point, and is not promoted to the API.<br>
<br>
Only thing I wanted to note was that the name of the existing list
of creds 'shibboleth.DefaultEncryptionCredentials' felt wrong since
it's supposed to be *all* of them. So in wiring in
relying-party-system.xml I use as the well-known bean name
'shibboleth.EncryptionCredentials', which is more parallel to the
'shibboleth.SigningCredentials' that we earlier added. In
credentials.xml, I just then did an <alias> by default, with a
note that it could be redefined as a real bean:<br>
<br>
<tt> <!--</tt><tt><br>
</tt><tt> The list of ALL of your IdP's encryption credentials.
By default this is just an alias</tt><tt><br>
</tt><tt> for 'shibboleth.DefaultEncryptionCredentials'. It could
be re-defined as</tt><tt><br>
</tt><tt> a list with additional credentials if needed.</tt><tt><br>
</tt><tt> --></tt><tt><br>
</tt><tt> <alias alias="shibboleth.EncryptionCredentials"
name="shibboleth.DefaultEncryptionCredentials" /></tt><tt><br>
</tt><br>
<br>
Like the signing case, the wiring uses getObject(), so legacy
configs won't break if the bean doesn't exist.<br>
</body>
</html>