SP metadata: certificate for signing and encryption
Peter Schober
peter.schober at univie.ac.at
Tue Jul 15 03:25:46 EDT 2014
* Alexey <strolling.code at gmail.com> [2014-07-15 07:14]:
> As far as I know, for the sending of secure data in both directions, I
> should have:
>
> 1. My own private key
> 2. My own public key
> 3. Recipient's public key
>
> Certificate of what key I should specifying in the SP- metadata and сan I
> use the same certificate for signing and encryption? Part of the SP-
> metadata file:
On RPM systems the SP will call /etc/shibboleth/keygen.sh to create a
pre-configured key pair, of which all the right parts will be availabe
at /Shibboleth.sso/Metadata
So if you don't know what goes where, the software already did it all
for you, correctly.
Your private key (used for signing SAML protocol messages) does NOT go
into SAML metadata, it stays *private* to your system (in the file
system).
Your public key goes into the SAML metadata and can be used by IDPs to
encrypt SAML protocol messages to your SP. If you're using the same
keypair for both encryption and signing (still the default in the
release software) you're signalling that by absence of a 'use'
attribute on the KeyDesriptor, otherwise (for seperate key pairs,
i.e., two private keys and two public keys) you publish both public
keys and indicate what key to 'use' for what; use="siging" will signal
that the modulus from a given public key is the one the SP will use to
sign its SAML protocol messages. (Not that the SP signs messages by
default.)
Anyone else's public keys will be available to the SP in metadata in
pretty much the same way.
If none of this makes sense, don't change the defaults until you
do. As simple as that.
-peter
More information about the users
mailing list