IdP credentials for delegation Assertion signature validation

[Brent Putman]

On 8/20/15 6:36 AM, Rod Widdowson wrote:
> Not understanding the delicacies of what you need to do, but from a configuration point of view
>
>> 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.
> 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

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).

>
> 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.

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.


>
> 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.


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.

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. :

<util:list id="shibboleth.DefaultSigningCredentials">
    <bean id="shibboleth.DefaultSigningCredential"
         
class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean"
          p:privateKeyResource="%{idp.signing.key}"
          p:certificateResource="%{idp.signing.cert}"
          p:entityId-ref="entityID" />
</util:list>

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150820/486fe6e4/attachment.html>