Shibboleth uses server PKI at three distinct points in the flows. The first is used by SSL to authenticate the authentication service protecting the SSO handler to the browser. This is defined in Apache's configuration(httpd.conf
) for the main SSL port, 443. The initial authentication assertion is signed by use of a certificate defined in the <Credentials>
element of IdP.xml
. The attribute query handler is also protected by SSL, but usually on a separate port or server. A different set of SSL credentials may also be used to protect the attribute query handler for several reasons; bugs within Tomcat and Apache's SSL implementations, the difference in server types, and because federations and web browsers may have different sets of trusted roots. However, in many situations, one set of credentials can be used for all three purposes.
Example usage:
<Credentials xmlns="urn:mace:shibboleth:credentials:1.0"> <FileResolver Id="mycerts"> <Key> <Path>file:/usr/local/shibboleth-idp/etc/supervillain.key</Path> </Key> <Certificate> <Path>file:/usr/local/shibboleth-idp/etc/supervillain.crt</Path> </Certificate> </FileResolver> </Credentials> |
|
This element is the container for credentials used by the credential mechanism specified by the |
Flat-file based certificate storage and protection is by far the most straightforward and common credential storage mechanism. Shibboleth supports .pem
and .der
encodings. These certificate files may be easily shared by both Apache and Shibboleth in the common case where the same key and cert are used for all flows.
It is critical that these files be stored with appropriate permissions in an appropriate location. They must be readable by both Apache and Tomcat, but access should be extremely restricted beyond that. Any compromise of these files represents a compromise of your entire Identity Provider. Revoke the certificate immediately.
|
This element defines a pair of files used to store a private key and certificate associated with a given identifier and is contained by the |
|
This specifies the certificate corresponding to this set of credentials. Certificates are supported in a variety of automatically detected formats: DER, PEM, PKCS8, PKCS12, and all associated encrypted forms. The certificate itself must be referred to using a |
|
This specifies the file containing a private key to be used by a set of credentials. Keys are supported in a variety of automatically detected formats: DER, PEM, PKCS8, PKCS12, and all associated encrypted forms. For encrypted keys, the password may be specified by adding an optional |
|
Paired with a |
|
This mandatory element specifies the path to a file or directory utilized by other elements of the configuration. It may be contained by various elements to point to different types of files required by the !IdP. |
Java keystores provide a native, integrated way to store credentials for use by the Shibboleth !IdP, Java-based authentication, and other Java applications. This storage mechanism may be preferred when attempting to run Shibboleth primarily through Java, or other applications need to share the same credentials. These certificates cannot be directly used by Apache for SSL protection of the protocol handlers, and using Tomcat to protect the attribute query handler is problematic for several reasons. Shibboleth includes extkeytool
to export flat-file certificates for Apache as well.
Be aware that Java keystores have not always maintained backwards -- or forwards -- version compatibility when Java's security libraries are updated. This may cause inspecific failures to load certificates, and is remedied by exporting all information in the keystore and re-importing it to a brand new keystore created by the same JDK as will be processing it.
|
This element is contained by the |
|
Specifies the alias for the certificate corresponding to the private key. If no alias is specified, defaults to the private key's alias. Contained by the |
|
Specifies the alias used for accessing the private key. Contained by the |
|
Specifies the password used to retrieve the private key. Contained by the |
|
Specifies the password to access the keystore containing the private key to be used for symmetric encryption. Contained by the |
|
This mandatory element specifies the path to a file or directory utilized by other elements of the configuration. It may be contained by various elements to point to different types of files required by the !IdP. |
SSL protection is used at two points in the Shibboleth flows: between the browser user and the authentication service, and between the remote attribute requestor and the attribute query handler. The OpenSSL libraries via Apache are used by Shibboleth for SSL functionality and certificate validation. For many reasons, it is desirable to separate these two services into separate virtual hosts and/or ports:
SSLVerifyClient
directive may not be declared within a <Location>
block. Leaving SSLVerifyClient
enabled for all flows will include that with browser users, which will confuse poorly-implemented web browsers.Shibboleth utilizes SSL protection of the flows handling attribute requests not only to protect against MITM attacks and confidentiality, but also to identify both principals in the exchange. SSLVerifyClient
must be present at a level of either required
or optional
. Depending on configuration settings, this may be the only identity-proofing of the remote requestor that is performed by the !IdP. If this interaction is misconfigured, or one party does not recognize the other, the SP will be treated as an unauthenticated requester and will only ever be eligible to receive the base set of attributes available to everyone.
Individual certificates or a trusted root list will be distributed by federations as part of metadata.xml
.
One of the most common problems encountered is a misconfigured SSLVerifyDepth
. This parameter defines how many links the SSL engine will follow on a certificate chain. If this is set too shallow, often to 0 or 1 hops, trust errors will occur since it can't follow the chain back to a trusted root; an arbitrarily high number such as 10 is recommended. Even though OpenSSL doesn't perform validation of other parts of the transaction, this will still cause failure anyway.
Standard SSL protection of the SSO handler and authentication system should work with minimal changes to default Apache configuration. Ensure that the proper port and protocol(=http*s*://=) are being referenced in relying party metadata.
The JDK includes the command line program keytool
for managing Java keystores. This utility cannot import or export private key information, making it difficult to use the same private key and certificate for Apache and Java-based applications. The Shibboleth distribution includes extkeytool
, a program that can be used in conjunction with keytool
to perform these tasks. Select the appropriate step-by-step procedure for your situation from the following guides. Before running extkeytool
, the variable SHIB_HOME must be set to the path to the directory where the Shibboleth tarball was exploded(typically =/opt/shibboleth-idp-1.3c-install/=).
keyEntry
containing the key you would like to use in your Apache setup. Assuming that your keystore is named yourstore
, the following command should present a list of the entries in the keystore: $ keytool -list -v -keystore yourstore
youralias
and the password for the keystore is yourpass
, enter the following command to export the key in Base64-encoded pkcs8
format:
$ extkeytool -exportkey -keystore yourstore -alias youralias -storepass yourpass -rfc -file yourkey.pkcs8 |
$ openssl pkcs8 -in yourkey.pkcs8 -nocrypt|openssl rsa -out yourkey.key |
$ openssl pkcs8 -in yourkey.pkcs8 -nocrypt|openssl rsa -des3 -out yourkey.enckey |
$ keytool -export -keystore yourstore -alias youralias -rfc -file yourcert |
mod_ssl
SSLCertificateKeyFile
and SSLCertificateFile
directives to point to the two files you have just created. Take care to remove any temporary files you created (i.e. =yourkey.pkcs8=) and set appropriate file permissions, especially if you chose to store the key in an unencrypted format.pkcs8
format. Assuming your PEM-encoded key is stored in a file named yourkey.enckey
, enter the following command.
$ openssl pkcs8 -in yourkey.enckey -topk8 -nocrypt -outform DER -out yourkey.der.pkcs8 |
mycert
and the CA signer certificate is stored in a file named ca.cert
, you might enter the following command to create the bundle.
$ cat mycert ca.cert > cert.bundle |
mod_ssl
enabled Apache installations include a number of commonly recognized CA certificates in the ca-bundle.crt
file under the $ServerRoot/conf/ssl.crt/
directory.JKS
keystore.
$ keytool -genkey -keyalg RSA -alias "selfsigned" -keystore yourstore -storepass "secret" -validity 360 |
$ keytool -delete -alias "selfsigned" -keystore yourstore -storepass "secret" |
yourstore
with a password of of yourpass
, enter the following command to store the data under the alias youralias
.
$ ./extkeytool -importkey -keystore yourstore -alias youralias -storepass yourpass -keyfile yourkey.der.pkcs8 -certfile cert.bundle -provider org.bouncycastle.jce.provider.BouncyCastleProvider |
$ keytool -list -v -keystore yourstore -alias youralias |
yourkey.der.pkcs8
, as it contains your unencrypted private key.yourkey
with an appropriate name to use to refer to the key.
$ openssl genrsa -des3 -out yourkey.enckey 1024 |
$ openssl req -new -key yourkey.enckey |
mod_ssl !SSLCertificateKeyFile
directive to point to the key file you just created and the SSLCertificateFile
directive to point to the file containing the certificate issued by the Certificate Authority. Previous sections explaion how to share the key/certificate pair with a Java keystore.