Sie sind auf Seite 1von 34

Shibboleth 2.

0 IdP
Training:
Basics and
Installation
January, 2009
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
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
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
IdP Basics: Terms
Profile
A description of how to use SAML to
accomplish a specific task
Profiles define the interface for SAML
peers
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
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
IdP Installation
Prerequisites
Prerequisite What were using
Java Virtual Machine Sun Java SE 6
Java Servlet Container Apache Tomcat 6
HTTP Listener Apache HTTPD 2.2 + mod_proxy_ajp 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
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
Shibboleth Home
(SHIB_HOME)
/opt/shibboleth-idp should contain






The Shibboleth documentation refers to
this directory as SHIB_HOME
bin logs
conf metadata
credentials war
lib
SHIB_HOME/bin
Contains command line tools
aacli: attribute authority command line
interface
version: returns the IdP version
SHIB_HOME/conf
Contains the IdPs configuration files:




We will cover most of these today
attribute-filter.xml logging.xml
attribute-resolver.xml login.config
handler.xml relying-party.xml
internal.xml service.xml
SHIB_HOME/credenti
als
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
SHIB_HOME/lib
Copies of libraries in the WAR file that
make up the IdP
Used by the command line tools
SHIB_HOME/logs
Contains the IdP log files
idp-process.log*
idp-access.log
idp-audit.log


* Often referred to when troubleshooting
SHIB_HOME/metadat
a
Contains metadata files
Files placed in this directory are not
automatically loaded
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
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
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.)
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
Logging
Configured using the logging.xml file
5 Logging levels
ERROR
WARN
INFO
DEBUG
TRACE
Lab: Logging
Change the logging level of the
edu.internet2.middleware.shibboleth
logger and evaluate the difference in the
logging messages
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
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
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
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
Metadata: Filesystem
Provider
The Filesystem metadata provider loads
a metadata file from the local filesystem.
Use type definition:
xsi:type="FilesystemMetadataP
rovider"
Configuration attribute
metadataFile
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
Lab: Metadata
Providers
Define a file-backed HTTP metadata
provider
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
Metadata Registration
Metadata must be shared between
relying parties
Federations typically have a centralized
registration process and systems
Register certificates and profiles
Lab: Metadata
Registration
Register your IdP so it can interact with
the SP/DS in the lab
References
More information on IdP basics and installation
can be found at:

https://spaces.internet2.edu/display/SHIB2/Inst
allation