IdPSPLocalTestInstall
Local Installation Recipe
The directions are for creating a sandbox'ed installation for testing purposes. They should never be used for a production installation.
We recommend all installers start with one provider and test it against a known relying party first because it's less confusing overall and simpler to troubleshoot one installation at a time. However, if you're in an environment where that's impossible, due to firewalls or policy rules, please follow the steps below closely.
Preparation
sp.machine will be the SP domain. You can replace it in all instructions, or map it to an address using
/etc/hosts.idp.machine will be the IdP domain. You can replace it in all instructions, or map it to an address using
/etc/hosts. We'll be using an Apache-based installation to allow these to optionally co-exist on the same machine.Both machines can be hosted on the same machine, or they can be virtual hosts, or they can be on separate machines.
Port 80 and 443 need to be open. Watch out for firewalls and permission problems.
Using a RedHat derivative(e.g. CentOS 5) is simplest.
IdP Installation
Download and install Java 1.5+, Tomcat 6.0 and Apache 2.2+. Install Tomcat at
/usr/local/tomcat. Avoid other distributions of Tomcat, such as fromyum. Make sure the$JAVA_HOMEenvironment variable points at the root of your JDK.Download the IdP .bin binary installer from http://shibboleth.net/downloads/identity-provider/latest/, unzip it, and move to that directory. The following is an example and may point to an older version.
curl -O [http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identityprovider-2.3.8-bin.zip unzip shibboleth-identityprovider-2.3.8-bin.zip cd identityprovider/Run ./install.sh (./install.bat on Windows). This is a new installation. Please use
/opt/shibboleth-idpfor your IdP directory.$ ./install.shConfigure Apache by adding the following line to
httpd.conforssl.confin the SSL virtual host to pass requests for the IdP into Tomcat:ProxyPass /idp/ ajp://localhost:8009/idp/Enable Tomcat to run the IdP by endorsing additional libraries for XML processing. You will need to make the endorsed directory.
mkdir /usr/local/tomcat/endorsed/ cp endorsed/*.jar /usr/local/tomcat/endorsed/Change Tomcat's
/usr/local/tomcat/conf/server.xmlport 8009 AJP13 connector. We'll add request.tomcatAuthentication="false" and Address="127.0.0.1" to allow Apache to send usernames to the IdP.<Connector port="8009" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" request.tomcatAuthentication="false" address="127.0.0.1" />Define the following in
httpd.conforssl.confto force users to authenticate when accessing the RemoteUser handler.<Location /idp/Authn/RemoteUser> AuthType Basic AuthName "My Identity Provider" AuthUserFile /usr/local/idp/credentials/user.db require valid-user </Location>Create a test user or two using the
htpasswdcommand.htpasswd -c /usr/local/idp/credentials/user.db myselfDeploy the WAR to Tomcat.
cp /opt/shibboleth-idp/war/idp.war /usr/local/tomcat/webapps/
SP Installation
The installation of the SP is different depending on your platform. Please follow the right instructions for your machine. Linux RPM installation for Apache is simplest. IIS is most complex due to host mapping. Return here when you're done.
Basic Configuration
We need to configure the providers to talk to each other. Please make these precise changes.
The SP configuration files are in /etc/shibboleth/ for an RPM-based installation.
SP: shibboleth2.xml:
Change the
entityIDon the<ApplicationDefaults>element to https://sp.machine/shibboleth. This is your SP's name.Change the
entityIDon the<SSO>element to https://idp.machine/idp/shibboleth. This is your IdP's name, and will send users directly to your IdP's login service (via the location specified in its metadata).Uncomment the remotely maintained metadata example
<MetadataProvider>. This will describe the IdP to your SP. Change theurito point to http://idp.machine/idp/profile/Metadata/SAML. Delete or comment out both of the<MetadataFilter>elements as they will not allow the metadata being loaded from the IdP host to work.
SP: shibd.logger: Set DEBUG logging using log4j.rootCategory=DEBUG, shibd_log.
The IdP configuration files are in /opt/shibboleth-idp/conf/.
IdP: relying-party.xml:
Uncomment the
MetadataProvider reading metadata from a URL. Change themetadataURLto http://sp.machine/Shibboleth.sso/Metadata. This will describe a basic SP to your IdP; for more advanced deployments, you'll need to hand-edit that metadata to reflect more advanced use cases.Comment out the
MetadataFilterelement contained in theMetadataProviderelement. The metadata is unsigned, so this filter would cause the metadata to fail to load.
Restart Tomcat, Apache, and shibd.
Login Testing
Access https://sp-machine/secure using a web browser. Don't forget the https.
This is the fake location we protect for testing by default. It would be the URL of the application you want to protect. You should be redirected to your IdP, asked to login, and then see a 404 or This page could not be displayed error. That's because there is no real webpage at /var/www/html/secure/index.html, but you can create one. Go to https://sp-machine/Shibboleth.sso/Session with the same web browser. You should see basic login information. You now have a full login system, but attributes aren't enabled yet. If you have problems, here's the troubleshooting page.
Attribute Configuration
The easiest way to add attributes is to set up an LDAP directory. However, we can fake a lot using the built-in staticAttributes. The configuration directories are the same.
SP: attribute-map.xml: Uncomment all the sets of attribute mappings you can find. This tells the SP to listen for many common attributes.
IdP: attribute-resolver.xml: The IdP acquires attributes to send to the SP using this file.