Include RSAKeyValue In Assertions in IDP v3

Brent Putman putmanb at georgetown.edu
Tue Nov 8 16:57:50 EST 2016



On 11/8/16 4:34 PM, Brent Putman wrote:
>
>
>
> On 11/8/16 10:05 AM, Cantor, Scott wrote:
>>
>> I know you need a custom SecurityConfiguration on a relying party, and
>> you'd probably need to override the SigningConfiguration slot with an
>> object with a non-default keyInfoGeneratorManager property.
>
> Yes, that's pretty much the gist of it.
>

Actually, just looking at it quickly, there's another route to this.  It
does not emit the KeyValue by default if what you have is an
X509Credential.  However, we already will emit the KeyValue (and
DEREncodedKeyValue) by default if the signing cred is a basic public key
Credential, not an X509 one.  I think we already support wiring a
non-X509 cred in the IdP [1], so I think you could just wire up such a
credential and follow the instructions here [2] on setting up a
per-profile credential to use that instead of your default X509 one.

Note that this approach won't emit any cert stuff obviously, so if you
needed the X509Data AND the KeyValue, then this won't work and you need
to do the full thing similar to below.

You can reuse the private key from your existing X509 cred obviously,
and get the naked public key by extracting it from your cert (unless we
already save the naked signing public key on an IdP install, I don't
know off-hand).



>
> Once I get the immediate 3.3.0 release stuff out of the way, I'll look
> to see if I have an example lying around.  If not, I'll cook one up. 
> This might be slightly more complex than some of the other security
> conf overrides since you need to build a new generator factory
> instance(s), which go into the Manager.
>

If anyone really wants to give this a try in the interim, what you need
to do is 1) replicate something like the code below from
DefaultSecurityConfigurationBootstrap to build the
KeyInfoGeneratorManager in Spring wiring  2) change the X509 factory to
emit the KeyValue (e.g. equiv of 
x509Factory.setEmitPublicKeyValue(true)) and 3) set this manger on a
signature signing config instance on the property
keyInfoGeneratorManager.  There's a couple of non-Java bean-y things in
there, so probably need some use of Spring bean syntax's factoryMethod
and factoryBean, etc.

If this is a common need, we could look to simplify some of this with a
custom factory bean.


    protected static NamedKeyInfoGeneratorManager
buildSignatureKeyInfoGeneratorManager() {
        NamedKeyInfoGeneratorManager namedManager = new
NamedKeyInfoGeneratorManager();
       
        namedManager.setUseDefaultManager(true);
        KeyInfoGeneratorManager defaultManager =
namedManager.getDefaultManager();
       
        // Generator for basic Credentials
        BasicKeyInfoGeneratorFactory basicFactory = new
BasicKeyInfoGeneratorFactory();
        basicFactory.setEmitPublicKeyValue(true);
        basicFactory.setEmitPublicDEREncodedKeyValue(true);
        basicFactory.setEmitKeyNames(true);
       
        // Generator for X509Credentials
        X509KeyInfoGeneratorFactory x509Factory = new
X509KeyInfoGeneratorFactory();
        x509Factory.setEmitEntityCertificate(true);
        x509Factory.setEmitEntityCertificateChain(true);
       
        defaultManager.registerFactory(basicFactory);
        defaultManager.registerFactory(x509Factory);
       
        return namedManager;
    }



[1]
https://wiki.shibboleth.net/confluence/display/IDP30/CredentialBeanFactories

[2]
https://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfiguration#SecurityConfiguration-SigningandEncryptionConfiguration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161108/3e42a9eb/attachment.html>


More information about the users mailing list