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
- IdP Installation
- SP Installation
- Basic Configuration
- Login Testing
- Attribute Configuration
- Attribute Testing
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.
- Make sure your clocks are set properly.
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_HOME
environment 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-idp
for your IdP directory.$ ./install.sh
Configure Apache by adding the following line to
httpd.conf
orssl.conf
in 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.xml
port 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.conf
orssl.conf
to 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
htpasswd
command.htpasswd -c /usr/local/idp/credentials/user.db myself
Deploy 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
entityID
on the<ApplicationDefaults>
element tohttps://sp.machine/shibboleth
. This is your SP's name. - Change the
entityID
on the<SSO>
element tohttps://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 theuri
to point tohttp://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 themetadataURL
tohttp://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
MetadataFilter
element contained in theMetadataProvider
element. 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.
- Uncomment the
Example Static Connector
. - Uncomment the
eduPerson
attribute definitions except for eduPersonTargetedID and eduPersonTargetedID.old, and all the others you'd like. The eduPersonTargetedID definitions rely on a computed attribute definition that we won't have available. - Add a
<resolver:Dependency ref="staticAttributes" />
to theeduPersonEntitlement
andeduPersonAffiliation
attribute definitions, just like themyLDAP
examples. - Comment out the existing dependencies for
<resolver:Dependency ref="myLDAP" />
in the attribute definitions you've uncommented, unless you're also also using the example<resolver:DataConnector id="myLDAP">
from the distributed resolver configuration.
IdP: attribute-filter.xml
: This tells the IdP which attributes to send to which SP. We're going to send two more attributes to your SP.
- Uncomment the last
<AttributeFilterPolicy>
, with the portal example. - Change the
<PolicyRequirementRule>
value ofurn:example.org:sp:myPortal
tohttps://sp-machine/shibboleth
. - Change the
<AttributeRule>
attributeID
toeduPersonAffiliation
. - Create a second, identical
<AttributeRule>
with anattributeID
ofeduPersonEntitlement
.
It should look like this:
<AttributeFilterPolicy> <PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sp-machine/shibboleth" /> <AttributeRule attributeID="eduPersonAffiliation"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> <AttributeRule attributeID="eduPersonEntitlement"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy>
Restart Tomcat, Apache, and shibd
.
Attribute Testing
Access https://sp-machine/secure
using a web browser. Don't forget the https
. Go to https://sp-machine/Shibboleth.sso/Session
with the same web browser. You should see a couple attributes. You can find more information in /var/log/shibboleth/shibd.log
. If you have problems, here's the troubleshooting page.