Configuring a Shibboleth Service Provider (Target) for SDSS
We assume you have already installed the Shibboleth 1.2 software itself, as described in the deployment guide at http://www.switch.ch/aai/docs/shibboleth/internet2/1.2/deploy-guide-target1.2.1.html
First, find the shibboleth.xml configuration file and go to that directory (usually shibboleth/etc/shibboleth under the Shibboleth installation directory).
Download the certificate used to sign the SDSS metadata from http://sdss.ac.uk/fed/sdss.pem. To avoid being spoofed into allowing access to fake origins, ideally you should verify the fingerprint of the certificate like this:
openssl x509 -fingerprint -noout < sdss.pem
The correct fingerprint value must be determined offline from a member of the SDSS team to guard against the possibility of this web site being compromised.
Find the Shibboleth siterefresh executable file. Download the sites metadata as sdss-sites-12.xml and verify that it is signed correctly, as shown:
path/to/siterefresh --url http://sdss.ac.uk/fed/sdss-sites-12.xml --out sdss-sites-12.xml --cert sdss.pem
Similarly, download and verify the SDSS trust metadata file:
path/to/siterefresh --url http://sdss.ac.uk/fed/sdss-trust-12.xml --out sdss-trust-12.xml --cert sdss.pem
You must arrange to run these two commands regularly as a cron job to keep the metadata up to date. This ensures that users of new origins joining the federation will be able to access your services and prevents access being granted to users of origins that leave the federation.
Edit shibboleth.xml as follows. Change the providerId in the <Applications> element to the URN you gave when joining the SDSS Federation:
<Applications xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
id="default"
providerId="urn:mace:ac.uk:sdss.ac.uk:provider:service:yourdomain.ac.uk">
Note that the above suggested value for providerId might not match the URN you gave when you joined the Federation: check the <DestinationSite> element Name value in the metadata for your site in sdss-sites-12.xml, which is definitive.
Change the wayfURL in the <Sessions> element to https://wayf.sdss.ac.uk/shibboleth-wayf/WAYF
Change the first <FederationProvider> URI from the default IQ-sites.xml to the sdss-sites-12.xml file downloaded previously. You may wish to also delete the second (inline) <FederationProvider> element, the one containing the inline <SiteGroup> element for https://example.org/shibboleth, up to and including its closing </FederationProvider> line.
Similarly, change the <TrustProvider> URI from IQ-trust.xml to the sdss-trust-12.xml file downloaded previously.
Change <saml:Audience> from the default urn:mace:inqueue to:
<saml:Audience>urn:mace:ac.uk:sdss.ac.uk:federation:sdss</saml:Audience>
Within the <CredentialUse> element, add a <RelyingParty> element for the SDSS federation:
<RelyingParty Name="urn:mace:ac.uk:sdss.ac.uk:federation:sdss" TLS="sdssCreds" Signing="sdssCreds"/>
Within the <`Credentials> element, add a <FileResolver> element defining the "sdssCreds" identifier:
<FileResolver Id="sdssCreds">
<Key format="PEM">
<Path>.../apache/conf/ssl.key/shibbox.uni.ac.uk.key</Path>
</Key>
<Certificate format="PEM">
<Path>.../apache/conf/ssl.crt/shibbox.uni.ac.uk.crt</Path>
<CAPath>path/to/secureroots_new.crt</CAPath>
</Certificate>
</FileResolver>
- shibbox.uni.ac.uk.key
- is the key you generated and sent to the CA in the GetGlobalSignCert procedure. If you encrypted the key, a password must be given in the <Key> element: <Key format="PEM" password="your password">
- shibbox.uni.ac.uk.crt
- is the signed certificate file returned by the CA, corresponding to the key.
- secureroots_new.crt
- only applies to GlobalSign certificates. It is the chain of intermediate CA certificates between the shibbox.uni.ac.uk.crt certificate and CA's root certificate. For GlobalSign certificates, this can be downloaded from http://support.globalsign.net/en/serversign/root_install_ap.cfm (follow the secureroots_new.crt link). For the SDSS CA and Thawte, the <CAPath> line should be omitted, because their certificates are directly signed by a root CA (there are no intermediate CAs).
The .../apache/conf paths shown above are the key and certificate directories conventionally used for Apache SSL. It is common practice to share certificates between Shibboleth and Apache in this way, but not compulsory.
Reconfigure Apache
If you are using SSL for the target web site and you want to use the same certificate as for Shibboleth (not necessary but usual), the SSL configuration part of Apache's httpd.conf should contain:
SSLEngine on SSLCertificateFile .../apache/conf/ssl.key/shibbox.uni.ac.uk.crt SSLCertificateKeyFile .../apache/conf/ssl.crt/shibbox.uni.ac.uk.key
These are the same files previously referenced by the "sdssCreds" <FileResolver> in shibboleth.xml.
It is also desirable to configure Apache to send the certificate of the CA that signed the server certificate (and any intermediate CAs) to the client browser. If this certificate chain is not provided, the browser may not be able to verify the server certificate and may report an error to the user. The chain to use obviously depends on what CA signed the server certificate. For GlobalSign server certificates, this is the same secureroots_new.crt file described previously:
SSLCertificateChainFile path/to/secureroots_new.crt
For certificates signed by the SDSS internal CA, the chain is just the CA root certificate, which can be downloaded from http://www.sdss.ac.uk/ca/sdss-ca.crt
SSLCertificateChainFile path/to/sdss-ca.crt
For Thawte certificates, again the chain is just the CA root certificate previously extracted from the zip file downloaded from http://www.thawte.com/roots/:
SSLCertificateChainFile path/to/ThawtePremiumServerCA.txt
Keeping Metadata Refreshed
Finally, as mentioned previously, siterefresh should be run as a regular cron job to keep your site's locally cached copies of the federation metadata (sdss-sites-12.xml, sdss-trust-12.xml) up to date.