Shibboleth 2.0 IdP Training: Basics and Installation

1. Shibboleth 2.0 IdP Training:Basics and Installation • January, 2009

2. IdP Basics: Terms – SAML • Security Access Markup Language • XML-based standard for authentication and authorization data interchange • Identity Provider – producer of assertions • Service Provider – consumer of assertions • Current Version: 2.0 • Shibboleth 2.0 implements SAML 2.0

3. IdP Basics: Terms – Entity ID • A unique URI for a Shibboleth Identity Provider (IdP) or Service Provider (SP) • The recommended format is a URL • https://idp.colostate.edu/idp/shibboleth • InCommon Federation uses URNs: • urn:mace:incommon:colostate.edu

4. IdP Basics: Terms – Relying Party • The SAML peer to which the IdP is communicating with • The peer in most cases for an IdP is an SP

5. IdP Basics: Terms – Profile • A description of how to use SAML to accomplish a specific task • Profiles define the interface for SAML peers

6. IdP Basics: Terms – Metadata • A description of the SAML features supported by a SAML entity • This includes the URLs for communicating with the entity • Shibboleth also uses this information to build technical trust between entities

7. IdP Installation Prerequisites • Three basic prerequisites for installation: • Java Virtual Machine • Java Servlet Container • HTTP Listener • You should be comfortable installing software on your platform

8. IdP Installation Prerequisites

9. Apache Tomcat Shibboleth Prerequisites • Set in TOMCAT_HOME/conf/server.xml • Turn off Apache Tomcat authentication (optional) • Set AJP listener to accept connections from localhost only

10. Lab: Shibboleth Installation • Unzip the distribution archive • Run an install script • Answer questions • Deploy a WAR file • Restart Tomcat and verify the installation on port 8080

11. Shibboleth Home (SHIB_HOME) • /opt/shibboleth-idp should contain • The Shibboleth documentation refers to this directory as SHIB_HOME

12. SHIB_HOME/bin • Contains command line tools • aacli: attribute authority command line interface • version: returns the IdP version

13. SHIB_HOME/conf • Contains the IdP’s configuration files: • We will cover most of these today

14. SHIB_HOME/credentials • Credentials used by the IdP • The installer creates these: • idp.key (IdP key) • idp.crt (certificate) • idp.jks (keystore) • You can use this directory to store Federation certificates

15. SHIB_HOME/lib • Copies of libraries in the WAR file that make up the IdP • Used by the command line tools

16. SHIB_HOME/logs • Contains the IdP log files • idp-process.log* • idp-access.log • idp-audit.log • * Often referred to when troubleshooting

17. SHIB_HOME/metadata • Contains metadata files • Files placed in this directory are not automatically loaded

18. SHIB_HOME/war • Contains the IdP WAR file created by the installer • Note that we configured Apache Tomcat to run the IdP directly from the WAR file

19. HTTP Listener • Apache Tomcat has a built-in HTTP listener and can be used as a standalone • Apache HTTPD is a web server often implemented as a HTTP listener for Tomcat • Using both can offer flexibility • And interface well with legacy components

20. Apache HTTPD and Tomcat • Use mod_proxy_ajp • Define VirtualHosts for the Shibboleth SAML profiles, which listen on ports 443 and optionally 8443 • mod_proxy directive to connect to Tomcat • Certificate settings • Others as required (logging, etc.)

21. Lab: Apache HTTPD • Configure Apache HTTPD as the HTTP listener for Apache Tomcat • mod_proxy_ajp has already been installed • Modify /etc/httpd/conf/httpd.conf • Add the ProxyPass for /idp • Restart Apache HTTPD

22. Logging • Configured using the logging.xml file • 5 Logging levels • ERROR • WARN • INFO • DEBUG • TRACE

23. Lab: Logging • Change the logging level of the edu.internet2.middleware.shibboleth logger and evaluate the difference in the logging messages

24. Metadata: General • Describes SAML features supported by the IdP and SP • Includes the URLs for communicating with the IdP and SP • Certificates for IdPs and SPs to trust each other • Federations will typically control and publish metadata

25. Metadata: Configuration • Metadata can be stored and loaded locally (use SHIB_HOME/metadata) • Metadata can also be loaded from a remote source • We will discuss both configurations

26. Metadata: Configuration • Metadata is loaded into the IdP by metadata providers • Metadata providers are defined in the relying-party.xml file • A single metadata “container” provider is defined where you will define within it your metadata providers

27. Metadata: Defining a Provider • Metadata providers are defined using the <MetadataProvider> element • Every metadata provider must have a: • Unique ID using the id attribute • Type using the xsi:type attribute • Each type of metadata provider has its own set of configuration attributes

28. Metadata: Filesystem Provider • The Filesystem metadata provider loads a metadata file from the local filesystem. • Use type definition: • xsi:type="FilesystemMetadataProvider" • Configuration attribute • metadataFile

29. Metadata: File-backed HTTP Provider • Loads metadata via HTTP and backs it up to local file • Type definition: • xsi:type="FileBackedHTTPMetadataProvider" • Configuration attributes: • metadataURL • backingFile

30. Lab: Metadata Providers • Define a file-backed HTTP metadata provider

31. Multiple Metadata Providers • The chaining metadata provider processes children metadata providers in the order they are defined • If the same entity is defined in more than one metadata provider, only the first definition found will be used

32. Metadata Registration • Metadata must be shared between relying parties • Federations typically have a centralized registration process and systems • Register certificates and profiles

33. Lab: Metadata Registration • Register your IdP so it can interact with the SP/DS in the lab

34. References • More information on IdP basics and installation can be found at: • https://spaces.internet2.edu/display/SHIB2/Installation