<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/20/15 6:36 AM, Rod Widdowson
wrote:<br>
</div>
<blockquote
cite="mid:012f01d0db34$2474ef90$6d5eceb0$@steadingsoftware.com"
type="cite">
<pre wrap="">Not understanding the delicacies of what you need to do, but from a configuration point of view
</pre>
<blockquote type="cite">
<pre wrap="">But turns out that we don't actually load that context in the root Spring
context or in any context visible to a flow. It's just used as a config resource
for the RelyingPartyConfigurationResolver service, which I guess has its own
context.
</pre>
</blockquote>
<pre wrap="">
This means that it is a reloadable file so you need to bear that in mind - you need to go through a service to get the info and I'd be inclined to leverage the one we have</pre>
</blockquote>
<br>
I was totally glossing over the fact that these are reloadable. So
I agree we definitely need to get at these via a reloadable service
(of some kind).<br>
<br>
<blockquote
cite="mid:012f01d0db34$2474ef90$6d5eceb0$@steadingsoftware.com"
type="cite">
<pre wrap="">
Can you get what you need from net.shibboleth.idp.profile.config.SecurityConfiguration? If so then you just need to plumb in shibboleth.RelyingPartyResolverService call getDefaultSecurityConfiguration on it and you are done.</pre>
</blockquote>
<br>
No, I don't think so. There could be many signing creds and the
exact one that was used certainly can't be assumed to be in the
default list. It might have been an RP-specific one not specified
in the default SecurityConfiguration.<br>
<br>
<br>
<blockquote
cite="mid:012f01d0db34$2474ef90$6d5eceb0$@steadingsoftware.com"
type="cite">
<pre wrap="">
Otherwise my suggestion would be either to add a method to do what you need to RelyingPartyConfigurationResolver and use shibboleth.RelyingPartyResolverService as per above.
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.
Or you could get completely radical and build your own Serviceable class which consumes (some of) the same beans as the RPConfig and from that build a service which takes the same input files as shibboleth.RelyingPartyResolverService and does exactly what you want. You could add some lazy-init to our configs if you thought that the duplication would cost memory, but I don't see that happening.
</pre>
</blockquote>
<br>
<br>
I think one of those is what I'm going to have to do. I'm starting
to get my head around all the reloadable service stuff now. Doing
it as a separate CredentialsService or somesuch feels cleaner than
tacking it onto the RP resolver (since it really has nothing to do
with relying parties per se). But I'll see what that would look
like.<br>
<br>
Either way, the thing I guess I would need agreement on is that: in
order for this to work, I believe we'd need to assume a new bean
structure in conf/credentials.xml. We'd need to have the deployer
wrap all the defined signing credentials in a new list, e.g. :<br>
<br>
<tt><util:list id="shibboleth.DefaultSigningCredentials"></tt><tt><br>
</tt><tt> <bean id="shibboleth.DefaultSigningCredential"</tt><tt><br>
</tt><tt>
class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"</tt><tt><br>
</tt><tt> p:privateKeyResource="%{idp.signing.key}"</tt><tt><br>
</tt><tt> p:certificateResource="%{idp.signing.cert}"</tt><tt><br>
</tt><tt> p:entityId-ref="entityID" /></tt><tt><br>
</tt><tt></util:list></tt><br>
<br>
So basically make it like the encryption ones already are (except
that the constituent beans would also need to have their own bean
ID's so they can be individually referenced). I doubt that's an
issue, but it's a change and new requirement for a user-space config
file. Also have to make 100% sure things don't blow up if the
haven't done that, obviously.<br>
<br>
</body>
</html>