Installing Shibboleth v2.5: Apache or Windows
Information included on this page will help you to install and use Web Login (Shibboleth) for authentication on an Apache or Windows server.
Step 1: Set Up Apache or Windows with SSL
Follow these steps to set up Apache or Windows with SSL:
Note: When configuring an Apache server, we recommend RedHat 5, CentOS 5, SUSE 11 or OpenSUSE 11 for use with Shibboleth. Other distributions may work, but will require additional steps beyond what is documented here.
- To set up and configure Apache or Windows with SSL encryption, refer to your distribution's instructions.
- Shibboleth should be used with TLS/SSL encrypted connections; for this you need an SSL certificate. To request a certificate using the CMU CA please visit the Certificate Authority web page.
Note: Shibboleth utilizes a self-signed certificate internally. This is different from the TLS/SSL web server certificate and is created by Shibboleth software itself.
- Follow your system's installation instructions to install the certificate received from the Certificate Authority.
- To connect to the Apache or Windows server on your computer, visit http://HOSTNAME/ (where HOSTNAME is your server name).
- To obtain an encrypted connection, visit https://HOSTNAME/. Note: Be sure to use "https" and not "http".
Note: You must establish an encrypted connection to your server in order to continue.
Step 2: Install Shibboleth
Depending on your system support style, follow the appropriate links to install Shibboleth and download necessary files. Once you've finished, return to this page and continue with Step 3 (below):
RPM-based system OR Compile from Source
- installation steps Wiki Shibboleth (Linux)
- download CMU Shibboleth configuration template cmu-linux-25-shibboleth2.xml
- download InCommon metadata signing certificate incommon.pem and store it to /etc/shibboleth/incommon.pem
- if your hostname and service name are NOT the same OR if the certificate that was created does NOT have a lifetime of ten years, see Delete/Recreate Certificates. Follow the Delete/Recreate Certificate steps to delete the certificates created by the installation and recreate them to match your service name OR to assure a lifetime of ten years.
In the RPM-based and Windows steps above, you can verify the InCommon metadata signing certificate by entering the following command; if the computed SHA1 Fingerprint agrees, the certificate is correct:
#openssl x509 -sha1 -in incommon.pem -noout -fingerprint
Step 3: Configure the Shibboleth Service
Most of the configuration for a Shibboleth service provider is in the /etc/shibboleth/shibboleth2.xml file. Note the following:
- On Linux systems, you must copy the shibboleth2.xml file that you downloaded in Step 2 to /etc/shibboleth/shibboleth2.xml.
- On Windows systems, you must copy the shibboleth2.xml file to you download in Step 2 to C:/opt/shibboleth-sp/etc/shibboleth/shibboleth2.xml
Next, edit the /etc/shibboleth/shibboleth2.xml file as follows:
- UPDATE THE ENTITYID TO REFLECT YOUR HOSTNAME. Remember to use the same hostname that was used with your certificate generation.
"REMOTE_USER="eppn persistent-id targeted-id">
- UPDATE THE SUPPORT CONTACT INFORMATION. The email address provided will be used when displaying error message pages or the logout page.
- ENABLE FETCHING: InCOMMON METADATA
Metadata is the information used to locate and establish trust between service provider and identity providers that use shibboleth. Carnegie Mellon identity and service providers are part of the InCommon Federation. To fetch the metadata from the InCommon Federation, one of the XML configuration blocks in shibboleth2.xml must be uncommented. Do one of the following:
- If your service is within SII, uncomment the following block:
uri="https://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml" backingFilePath="incommon-metadata.xml" reloadInterval="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="incommon.pem"/>
<TransportOption provider="CURL" option="10004">sii proxy.iso.cmu.edu:3128</TransportOption>
- If your service provider is directly on the Internet, uncomment the following block:<MetadataProvider type="XML"
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/><MetadataFilter type="Signature" certificate="incommon.pem"/>
The InCommon metatdata will be periodically fetched, its signature verified, and your service provider's metadata configuration will be updated automatically.
- SELECT THE DISCOVERY SERVICE OR A SINGLE IDENTITY PROVIDER
Shibboleth allows the use of a discovery service. This service permits a user to select which identity provider they will use for authentication. Alternatively, the service provider may configure one static identity provider to use. In the future Carnegie Mellon will be providing its own discovery service specific to identity providers available on campus. Do one of the following:
- If you want to use the InCommon Discovery Service, uncommment the following block:
discoveryURL="https://wayf.incommonfederation.org/DS/WAYF"> SAML2 SAML1 </SSO>
- If you want to use only the Carnegie Mellon Pittsburgh identity provider, uncommment the following block:
<SSO entityID="https://login.cmu.edu/idp/shibboleth"> SAML2 SAML1 </SSO>
Step 4: Registering your Service Provider with InCommon
At this point your system should have a properly configured shibboleth; however, it will NOT work until it is registered with InCommon Federation. To register, send an email message as follows.
Include the following in the message body:
- SP Host Name - This name should be the fully qualified DNS name that your audience will use to access your web service.
- SP Display Name - Include a user-friendly name for your service; please limit this to a few words.
- Registrants - List the name(s) and Andrew userID(s) of the people who you wish to register and their respective roles. Typically, the technical support person is registered, but you may also register administrative and support personnel as well.
- Copy contents of the sp-cert.pem file into the body of the message.
||To include additional elements, please see Optional Interface Elements.
You will be contacted once the registration is complete; you should allow two business days. After your system refreshes the InCommon Metata, your service provider will be functional.
Step 5: Testing Your Service Providers Configuration
- Using a web browser on your service provider, visit: https://localhost/Shibboleth.sso/Status. Information about your service provider should be displayed.
- Access https://HOSTNAME/secure. This will redirect your browser to either a discovery service or identity provider permitting you to login.
Note: If you do not have a secure directory configured in apache, access will fail.
Step 6: Protect Your Pages
Once you have completed all steps to install and configure Shibboleth, you can use it to protect a directory on your web server. Depending on your system support style, follow the appropriate steps below:
Last Updated: 05/16/13