SAML plugin - differentiate between encryption and signing certificate

[de_...@hotmail.com]

Hi , 

When setting up the Jenkins SAML plugin, is it possible to configure two different certificates (generated from the same private key) for signing and encryption? 

The plugin seems to allow to configure just one key alias from one keystore. (https://github.com/jenkinsci/saml-plugin/blob/master/doc/CONFIGURE.md)

I'ml looking to configure 

alias 1 = private key A + signing certificate chain C1

alias 2 = private key A+ encryption certificate chain C2

When enabling option 'Auth Request Signature' to  enable the signature of the Redirect Binding Auth Request, I can see two key descriptors being written to the saml-sp-metadata.xml file: 

<md:KeyDescriptor use="encryption">

            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

                <ds:X509Data>

                    <ds:X509Certificate>...

and 

 <md:KeyDescriptor use="signing">

            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

                <ds:X509Data>

                    <ds:X509Certificate>...

This leads me to believe that a setup with different sign and encryption certs is a possibility.

I've tried to configure the correct values for my setup directly in the saml-sp-metadata.xml file, but the file gets overwritten on each login attempt. 

Does the current implementation of the saml plugin dictate the encryption and signing cert to be the same and if not, how do I configure these? 

Kind regards, 

Chris

[Ivan Fernandez Calvo]

Hi,

The configuration only allows one certificate, this is used for singing and encryption, so it is not possible to use two different certificates.

[Chris DW]

Hi , 

Having a signing certificate different from the encryption certificate was a request from my IDP. 

So I created both seperately.(from the same private key) .

I was a bit confused as to the role of the saml-sp-metadata.xml being generated by the saml plugin.

The way I understand it now, is that is serves the purpose of helping the user to generate SP metadata from the Jenkins UI in order to forward the meta data to the IDP. 

It is not being used by the plugin 'at runtime'. 

Since I had already sent my SP meta-data prior to installing and configuring the SAML plugin, I wasn't required to do anything with the generated  saml-sp-metadata.xml  file. 

All I needed to do was set up a keystore with the proper private key (which in my case is the same for the encryption and signing certificate) 

Thanks for your time, 

Chris

Op dinsdag 28 juli 2020 20:07:54 UTC+2 schreef Ivan Fernandez Calvo: