URL: http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/install-sp-1.3-solaris.html
Author: Valery Tschopp - SWITCH
$Date: 2009/08/18 15:04:28 $
$Revision: 1.24 $ 

Install Shibboleth Service Provider 1.3.3 on Solaris 8

Table of Contents

Introduction

This guide describes Solaris specific installation of a Shibboleth Service Provider 1.3 and its configuration for the SWITCHaai Federation. It covers installation on Solaris 8 using Sun Studio 10, C/C++ 5.7 Compiler and with Apache 1.3, Apache 2.0 or Apache 2.2.

More extensive information can be found in the Shibboleth Service Provider Deployment Guide from Internet2. It is recommended to familiarize yourself with the Internet2 guide before starting with this document.

Note: For general information about the deployment of Shibboleth within the SWITCHaai Federation, please consult the Support & Downloads section of the SWITCHaai website (http://www.switch.ch/aai/).

Overview

The Shibboleth Service Provider (SP) 1.3 is implemented in C/C++ as an Apache authentification module mod_shib and a separate daemon shibd.

Prerequisites

As indicated in the title, this guide applies to Solaris 8 and contains some references to Solaris specific tools.

OpenSSL
Recommended Version >= 0.9.7
OpenSSL is used to handle server certificates and SSL connections.
Apache + mod_ssl
Recommended Apache version >= 1.3.33
Recommended mod_ssl version >= 2.8.22
The Apache will use mod_ssl to handle HTTPS connections.
NTP
Or any other software which provides time-synchronization
Servers running Shibboleth should have their system time synchronized in order to avoid clock-skews.

Installation of Shibboleth SP 1.3

The installation requires to compile the Shibboleth Service Provider 1.3 and some libraries from the sources. Therefore, you need to install the necessary building tools and development libraries on your compile host.

The Shibboleth SP 1.3 should be installed under: /opt/shibboleth-1.3.
Set the envrionment variable SHIB_HOME accordingly.

root# export SHIB_HOME=/opt/shibboleth-1.3

You may also include the following lines in /etc/profile:

SHIB_HOME=/opt/shibboleth-1.3
export SHIB_HOME

Solaris C/C++ Compilers and Building Tools

Note: It is required to use the same compiler for Shibboleth as the one you have used to build the OpenSSL library and Apache with mod_ssl.

Sun C/C++ Compiler

As our local OpenSSL library, Apache and mod_ssl were built with Sun Studio 10, C/C++ 5.7 Compiler, we needed to build the Shibboleth SP 1.3 and the required libraries using Sun Studio 10, C/C++ 5.7 Compiler too.

Sun Studio 10 C and C++ compilers are licensed softwares and normally installed under: /opt/SUNWspro
If it is not the case, contact your system administrator to install the Solaris packages (SPROcc and SPROcpl).

Set your PATH for Sun Forte Compilers and make:

user$ export PATH=/opt/SUNWspro/bin:/usr/ccs/bin:/usr/bin:/usr/local/bin
user$ cc -V
cc: Sun C 5.7 Patch 117836-02 2005/03/23
user$ CC -V
CC: Sun C++ 5.7 2005/03/01

GNU make

Besides the default Sun's make building tool, the GNU make (gmake) building tool is also required to build the Xerces-C and the XML-Security-C libraries.

You can download the GNU make precompiled binary package for Solaris directly from sunfreeware.com

OpenSSL Library

OpenSSL is a toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library.

Many site have already locally installed the OpenSSL libssl library. The libssl headers (include files) must also be installed to compile the other libraries.

Otherwise, you can build the libssl locally or download the OpenSSL precompiled binary package for Solaris directly from sunfreeware.com

Build and Install libcurl Library

cURL is a tool for transferring files with URL syntax, supporting HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, kerberos, HTTP form based upload, proxies, cookies, user+password authentication, file transfer resume, http proxy tunneling and a busload of other useful tricks. Project homepage: http://curl.haxx.se/libcurl

The last libcurl 7.19.6 is the preferred version to build Shibboleth SP 1.3.3. Due to a security vulnerability no earlier version should be used.

To build and install the libcurl library:

user$ export CC=cc
user$ export CXX=CC
user$ export CFLAGS="-fast -xtarget=ultra"
user$ export CXXFLAGS=$CFLAGS
user$ export MAKE=make
user$
user$ export OPENSSL=/usr/local
user$ wget http://curl.haxx.se/download/curl-7.19.6.tar.gz
...
user$ gunzip -c curl-7.19.6.tar.gz | tar xvf -
...
user$ cd curl-7.19.6
user$ ./configure --prefix=$SHIB_HOME --with-ssl=$OPENSSL \
       --without-ca-bundle --disable-static
...
user$ make 
...
user$ make install 
...

make install will install the libcurl shared library in /opt/shibboleth-1.3. Therefore, you must have write access to this directory.

Build and Install log4shib Library

The Shibboleth project of Internet2 is using a custom patched version of log4cpp under the name of log4shib. Make sure you build Shibboleth against this version or you'll risk to get an instable Shibboleth SP. Project homepage: https://spaces.internet2.edu/display/SHIB2/log4shib

Shibboleth SP 1.3.3 requires the library log4shib available from Internet2.

To build and install the log4shib library:

user$ export CC=cc
user$ export CXX=CC
user$ export CFLAGS="-fast -xtarget=ultra"
user$ export CXXFLAGS=$CFLAGS
user$ export MAKE=make
user$
user$ wget http://shibboleth.internet2.edu/downloads/log4shib-1.0.tar.gz
...
user$ gunzip -c log4shib-1.0.3.tar.gz | tar xvf -
...
user$ cd log4shib-1.0.3
user$ ./configure --prefix=$SHIB_HOME --disable-static --disable-doxygen
...
user$ make
...
user$ make install
...
make install will install the log4shib shared library in /opt/shibboleth-1.3. Therefore, you must have write access to this directory.

Build and Install Xerces-C++ Library

Xerces-C++ is an opensource validating XML parser written in a portable subset of C++. Xerces-C++ makes it easy to give your application the ability to read and write XML data. Project homepage: http://xerces.apache.org/xerces-c/

Shibboleth SP 1.3.3 requires version 2.8.0 of the Xerces-C++ library.

To build and install the Xerces-C++ library:

user$ export CC=cc
user$ export CXX=CC
user$ export CFLAGS="-fast -xtarget=ultra"
user$ export CXXFLAGS=$CFLAGS
user$
user$ export LDFLAGS="-R$SHIB_HOME/lib"
user$ export MAKE=gmake
user$
user$ wget http://xml.apache.org/dist/xerces-c/sources/xerces-c-src_2_8_0.tar.gz
...
user$ gunzip -c xerces-c-src_2_8_0.tar.gz | tar xvf -
...
user$ cd xerces-c-src_2_8_0
user$ export XERCESCROOT=`pwd`
user$
user$ cd src/xercesc
user$ ./runConfigure -p solaris -c $CC -x $CXX -r pthread -P $SHIB_HOME
...
user$ gmake
...
user$ gmake install
...
The Xerces-C++ shared library is now installed in /opt/shibboleth-1.3

Build and Install XML-Security C++ Library

The XML Security C++ library is an opensource implementation of the XML Digital Signature specification. Project homepage: http://xml.apache.org/security/

Shibboleth SP 1.3.3 requires version 1.5.1 of the XML-Security library.

To build and install the XML-Security C++ library:

user$ export CC=cc
user$ export CXX=CC
user$ export CFLAGS="-fast -xtarget=ultra"
user$ export CXXFLAGS=$CFLAGS
user$
user$ export XERCESCROOT=`pwd`/xerces-c-src_2_8_0
user$ export OPENSSL=/usr/local
user$ export LD_LIBRARY_PATH=/usr/local/lib
user$ export MAKE=gmake
user$ export LDFLAGS="-R$SHIB_HOME/lib"
user$
user$ wget http://xml.apache.org/security/dist/c-library/xml-security-c-1.5.1.tar.gz
...
user$ gunzip -c xml-security-c-1.5.1.tar.gz | tar xvf -
...
user$ cd xml-security-c-1.5.1
user$
user$ ./configure --prefix=$SHIB_HOME --without-xalan
...
user$ gmake
...
user$ gmake install
...
The XML-Security shared library is now installed in /opt/shibboleth-1.3

Build and Install OpenSAML Library

SAML (Security Assertion Markup Language) is a standard for the formation and exchange of authentication, attribute, and authorization data as XML. OpenSAML is an opensource library which can be used to build, transport, and parse SAML 1.0 and 1.1 messages. It is able to store the individual information fields that make up a SAML message, build the correct XML representation, and parse XML back into the individual fields before handing it off to a recipient. OpenSAML supports the SOAP binding for the exchange of SAML request and response objects. Project homepage: http://www.opensaml.org/

The OpenSAML 1.1.1 library is required by Shibboleth SP 1.3.3.

To build and install the OpenSAML library:

user$ export CC=cc
user$ export CXX=CC
user$ export CFLAGS="-fast -xtarget=ultra"
user$ export CXXFLAGS=$CFLAGS
user$
user$ export OPENSSL=/usr/local
user$ export MAKE=gmake
user$
user$ wget http://shibboleth.internet2.edu/downloads/opensaml-1.1.2.tar.gz
...
user$ gunzip -c opensaml-1.1.2.tar.gz | tar xvf -
...
user$ cd opensaml-1.1.2
user$ ./configure --prefix=$SHIB_HOME --with-curl=$SHIB_HOME --with-log4shib=$SHIB_HOME \
      --with-openssl=$OPENSSL
...
user$ gmake 
...
user$ gmake install 
...
The OpenSAML shared library is now installed in /opt/shibboleth-1.3

Build and Install Shibboleth SP 1.3.3

The Shibboleth SP 1.3.3 is an Apache dynamic loadable module. Therefore, it must be linked against Apache server and requires the Apache apxs or Apache2 apxs2 tool as well as the Apache header (include) files.

Building the Shibboleth Daemon shibd, the Apache modules, the extension and shared libraries is more or less like building OpenSAML.

To compile the Shibboleth SP 1.3.3 on Solaris x86, you need to apply on patch as described in https://bugs.internet2.edu/jira/browse/SSPCPP-81

The Shibboleth Service Provider (Shibboleth Daemon, Apache module, libraries, ... ) is now fully installed under /opt/shibboleth-1.3

Server Certificate

This section briefly mentions the needed steps to get a server certificate. For a full documentation how to get SWITCHpki certificates, see http://www.switch.ch/aai/certificates/get-switchpki-certificate.html

Generate Certificate

  1. Generate an unencrypted 2048-bit RSA key in PEM format:
    $ openssl genrsa -out www.example.ch.key 2048
    
  2. Create a Certificate Signing Request (CSR):
    $ openssl req -new -key www.example.ch.key -out www.example.ch.csr
    
  3. Send the CSR to your certification authority (CA) to be signed.
  4. Get your X509 server certificate (PEM format) signed with the full chain up to to the root CA certificate and save it under www.example.ch.crt.

Shibboleth SP 1.3 Configuration

Solaris Directories

On Solaris, all the system configuration files are stored in the directory /etc. Create a symbolic link to ease the Shibboleth configuration.

root# ln -s /opt/shibboleth-1.3/etc/shibboleth /etc/shibboleth

The /var/log/shibboleth logging directory doesn't exist. You have to create it and grant the user running Apache (in our case www) write access to it.

root# mkdir /var/log/shibboleth
root# chgrp www /var/log/shibboleth
root# chmod g+w /var/log/shibboleth

Key and Certificate

Copy the private key and certificate to the /etc/shibboleth directory:

root# cp www.example.ch.key /etc/shibboleth
root# cp www.example.ch.crt /etc/shibboleth
Make sure the permissions are set correctly. Only the user running Apache must be able to read the private key. Other users don't need to access the key file, so setting the correct ownership and access permissions is highly recommended.

shibboleth.xml

Download the shibboleth.xml file and store it as /etc/shibboleth/shibboleth.xml . This is the main configuration file for the Service Provider and is already preconfigured for the SWITCHaai federation.

Edit the /etc/shibboleth/shibboleth.xml file and configure your SP 1.3:

<SPConfig xmlns="urn:mace:shibboleth:target:config:1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:mace:shibboleth:target:config:1.0 shibboleth-targetconfig-1.0.xsd"
    clockSkew="180"
    logger="/etc/shibboleth/shibboleth.logger">

    <!-- These extensions are "universal", loaded by all Shibboleth-aware processes. -->
    <Extensions>
        <Library path="/opt/shibboleth-1.3/libexec/xmlproviders.so" fatal="true"/>
    </Extensions>

    <!-- The Global section pertains to shared Shibboleth processes like the shibd daemon. -->
    <Global logger="/etc/shibboleth/shibd.logger">
        
        <!-- Only one listener can be defined. -->
        <UnixListener address="/var/run/shibd.sock"/>
        <!-- <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/> -->
        
        <!--
        See deploy guide for details, but:
            cacheTimeout - how long before expired sessions are purged from the cache
            AATimeout - how long to wait for an AA to respond
            AAConnectTimeout - how long to wait while connecting to an AA
            defaultLifetime - if attributes come back without guidance, how long should they last?
            strictValidity - if we have expired attrs, and can't get new ones, keep using them?
            propagateErrors - suppress errors while getting attrs or let user see them?
            retryInterval - if propagateErrors is false and query fails, how long to wait before 
                            trying again
                            
        Only one session cache can be defined.
        -->
        <MemorySessionCache cleanupInterval="300" cacheTimeout="3600" 
            AATimeout="30" AAConnectTimeout="15"
            defaultLifetime="1800" retryInterval="300" 
            strictValidity="false" propagateErrors="false"/>
        
    </Global>
    
    <!-- The Local section pertains to resource-serving processes (often process pools) 
         like web servers. -->
    <Local logger="/etc/shibboleth/native.logger" localRelayState="true">
        <!--
        To customize behavior, map hostnames and path components to applicationId and other settings.
        The following provider types are available with the delivered code:
            type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider"
                - Web-server-specific plugin that allows native commands (like Apache's
                    ShibRequireSession) to override or supplement the XML syntax. The Apache
                    version also supplies an htaccess authz plugin for all content.

            type="edu.internet2.middleware.shibboleth.sp.provider.XMLRequestMapProvider"
                - portable plugin that does not support the older Apache-specific commands and works
                    the same on all web platforms, this plugin does NOT support htaccess files
                    for authz unless you also place an <htaccess/> element somewhere in the map

            By default, the "native" plugin (the first one above) is used, since it matches older
            behavior on both Apache and IIS.
        -->
        <RequestMapProvider type="edu.internet2.middleware.shibboleth.sp.provider.NativeRequestMapProvider">
            <RequestMap applicationId="default">
                <!--
                This requires a session for documents in /secure on the containing host with http and
                https on the default ports. Note that the name and port in the <Host> elements MUST match
                Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element
                below.
                -->
                <Host name="www.example.ch">
                    <Path name="secure" authType="shibboleth" requireSession="true" exportAssertion="true">
                        <!-- Example shows a subfolder on the SSL port assigned to a separate <Application> -->
                        <Path name="foo-admin" applicationId="foo-admin"/>
                    </Path>
                </Host>
            </RequestMap>
        </RequestMapProvider>
        
        <Implementation>
            <ISAPI normalizeRequest="true">
                <!--
                Maps IIS Instance ID values to the host scheme/name/port/sslport. The name is
                required so that the proper <Host> in the request map above is found without
                having to cover every possible DNS/IP combination the user might enter.
                The port and scheme can usually be omitted, so the HTTP request's port and
                scheme will be used.
                
                <Alias> elements can specify alternate permissible client-specified server names.
                If a client request uses such a name, normalized redirects will use it, but the
                request map processing is still based on the default name attribute for the
                site. This reduces duplicate data entry in the request map for every legal
                hostname a site might permit. In the example below, only sp.example.org needs a
                <Host> element in the map, but spalias.example.org could be used by a client
                and those requests will map to sp.example.org for configuration settings.
                -->
                <Site id="1" name="www.example.ch">
                    <!-- <Alias>www-alias.example.ch</Alias> -->
                </Site>
            </ISAPI>
        </Implementation>
    </Local>

    <!--
    The Applications section is where most of Shibboleth's SAML bits are defined.
    Resource requests are mapped in the Local section into an applicationId that
    points into to this section.
    -->
    <Applications id="default" 
        providerId="https://www.example.ch/shibboleth"
        homeURL="https://www.example.ch/"
        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
        xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">

        <!--
        Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
        You MUST supply an effectively unique handlerURL value for each of your applications.
        The value can be a relative path, a URL with no hostname (https:///path) or a full URL.
        The system can compute a relative value based on the virtual host. Using handlerSSL="true"
        will force the protocol to be https. You should also add a cookieProps setting of "; secure"
        in that case. 
        Note that if the value of checkAddress is set to "false", this has a slightly negative
        impact on the security of the SP. This security feature checks the user's IP address 
        at the SP and compares it with the IP address used at the IdP. If they don't match, an error 
        is thrown. This rather strict security feature can cause problems for users behind proxies 
        or for users with IPv6 addresses. Therefore, this setting is deactivated per default. 
        To compensate the slightly reduced security the consistentAddress feature is activated 
        in the default configuration.
        The consistentAddress feature is available as of version 1.3c for the  element. 
        It defaults to true when not present and ensures that once a session cookie is 
        issued to a client, any further use of that session cookie must be from a client with the 
        same network address. This raises the bar for session hijackers to the level of network 
        address spoofing, which may or may not be simple to do, but is definitely harder than
        stealing cookies and relies on a different set of attacking skills.
        On the other hand the consistentAddress may also cause problems for users whose IP changes 
        during the session (e.g. for AOL users or for users behind proxies 
        which have multiple IP addresses). 
        For additional information about the checkAddress and the consistentAddress setting have
        a look at https://spaces.internet2.edu/display/SHIB/AddressChecking
        -->
        <Sessions lifetime="7200" timeout="3600" checkAddress="false"
            handlerURL="/Shibboleth.sso" handlerSSL="false" 
            idpHistory="true" idpHistoryDays="7">
            
            <!--
            SessionInitiators handle session requests and relay them to a WAYF or directly
            to an IdP, if possible. Automatic session setup will use the default or first
            element (or requireSessionWith can specify a specific id to use). Lazy sessions
            can be started with any initiator by redirecting to it. The only Binding supported
            is the "urn:mace:shibboleth:sp:1.3:SessionInit" lazy session profile using query
            string parameters:
                 *  target      the resource to direct back to later (or homeURL will be used)
                 *  acsIndex    optional index of an ACS to use on the way back in
                 *  providerId  optional direct invocation of a specific IdP
            -->
            
            <!-- This default directs users to a specific SWITCHaai WAYF service. -->
            <SessionInitiator  id="SWITCHaai" isDefault="true" 
                Location="/WAYF/SWITCHaai"
                Binding="urn:mace:shibboleth:sp:1.3:SessionInit"
                wayfURL="https://wayf.switch.ch/SWITCHaai/WAYF"
                wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>
                            
            <!--
            md:AssertionConsumerService elements replace the old shireURL function with an
            explicit handler for particular profiles, such as SAML 1.1 POST or Artifact.
            The isDefault and index attributes are used when sessions are initiated
            to determine how to tell the IdP where and how to return the response.
            -->
            <md:AssertionConsumerService Location="/SAML/POST" index="1" isDefault="true"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
            <md:AssertionConsumerService Location="/SAML/Artifact" index="2"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>
            
            <!--
            md:SingleLogoutService elements are mostly a placeholder for 2.0, but a simple
            cookie-clearing option with a ResponseLocation or a return URL parameter is
            supported via the "urn:mace:shibboleth:sp:1.3:Logout" Binding value.
            -->
            <md:SingleLogoutService Location="/Logout" 
                Binding="urn:mace:shibboleth:sp:1.3:Logout"/>

        </Sessions>

        <!--
        You should customize these pages! You can add attributes with values that can be plugged
        into your templates. You can remove the access attribute to cause the module to return a
        standard 403 Forbidden error code if authorization fails, and then customize that condition
        using your web server.
        -->
        <Errors session="/etc/shibboleth/sessionError.html"
            metadata="/etc/shibboleth/metadataError.html"
            rm="/etc/shibboleth/rmError.html"
            access="/etc/shibboleth/accessError.html"
            supportContact="YOUR_EMAIL_ADDRESS"
            logoLocation="YOUR_LOGO_LOCATION"
            styleSheet="YOUR_STYLESHEET_LOCATION"/>

        <!-- Indicates what credentials to use when communicating -->
        <CredentialUse TLS="switchaai" Signing="switchaai">
            <!-- RelyingParty elements can customize credentials for specific IdPs/sets. -->
            <!--
            <RelyingParty Name="urn:mace:switch.ch:aaitest" TLS="aaitest" Signing="aaitest"/>
            -->
        </CredentialUse>
            
        <!-- AAP can be inline or in a separate file -->
        <AAPProvider type="edu.internet2.middleware.shibboleth.aap.provider.XMLAAP" 
            uri="/etc/shibboleth/AAP.switchaai.xml"/>
        
        <!-- Operational config consists of metadata and trust providers. Can be external or inline. -->

        <!-- SWITCHaai federation metadata (production) -->
        <MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.provider.XMLMetadata"
            uri="/etc/shibboleth/metadata.switchaai.xml"/>
        
        <!-- The standard trust provider supports SAMLv2 metadata with path validation extensions. -->
        <TrustProvider type="edu.internet2.middleware.shibboleth.common.provider.ShibbolethTrust"/>
                    
        <!--
        Zero or more SAML Audience condition matches (mainly for Shib 1.1 compatibility).
        If you get "policy mismatch errors, you probably need to supply metadata about
        your SP to the IdP if it's running 1.2. Adding an element here is only a partial fix.
        -->
        <!-- SWITCHaai federation -->
        <saml:Audience>urn:mace:switch.ch:SWITCHaai</saml:Audience>
        
        <!--
        You can customize behavior of specific applications here. The default elements inside the
        outer <Applications> element generally have to be overridden in an all or nothing fashion.
        That is, if you supply a <Sessions> or <Errors> override, you MUST include all attributes
        you want to apply, as they will not be inherited. Similarly, if you specify an element such as
        <MetadataProvider>, it is not additive with the defaults, but replaces them.
        
        Note that each application must have a handlerURL that maps uniquely to it and no other
        application in the <RequestMap>. Otherwise no sessions will reach the application.
        If each application lives on its own vhost, then a single handler at "/Shibboleth.sso"
        is sufficient, since the hostname will distinguish the application.
        
        The example below shows a special application that requires use of SSL when establishing
        sessions, restricts the session cookie to SSL and a specific folder, and inherits most other
        behavior except that it requests only EPPN from the origin instead of asking for all attributes.
        Note that it will inherit all of the handler endpoints defined for the default application
        but will append them to the handlerURL defined here.
        -->
        <!-- 
        <Application id="foo-admin">
            <Sessions lifetime="7200" timeout="3600" checkAddress="true"
                handlerURL="/secure/foo-admin/Shibboleth.sso" handlerSSL="true"
                cookieProps="; path=/secure/foo-admin; secure"/>
            <saml:AttributeDesignator AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName"
                AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"/>
        </Application>
        -->

    </Applications>
    
    <!-- Define all the private keys and certificates here that you reference from <CredentialUse>. -->
    <CredentialsProvider type="edu.internet2.middleware.shibboleth.common.Credentials">
        <Credentials xmlns="urn:mace:shibboleth:credentials:1.0">
            <FileResolver Id="switchaai">
                <Key>
                    <Path>/etc/shibboleth/www.example.ch.key</Path>
                </Key>
                <Certificate>
                    <!-- Certificate and the whole chain -->
                    <Path>/etc/shibboleth/www.example.ch.crt</Path>
                </Certificate>
            </FileResolver>
        </Credentials>
    </CredentialsProvider>
    
</SPConfig>

AAP.switchaai.xml

Download the Attribute Acceptance Policy file AAP.switchaai.xml and store it as /etc/shibboleth/AAP.switchaai.xml .

This file implements the AAI Attribute Specifications and maps the attributes to Apache environment variables. For more information about the specification, see the PDF document: http://www.switch.ch/aai/docs/AAI_Attr_Specs.pdf.

SWITCHaai Federation Metadata

Download the SWITCHaai metadata file metadata.switchaai.xml and store it as /etc/shibboleth/metadata.switchaai.xml .

The SWITCHaai federation metadata must be periodically updated to keep your resource up-to-date with the actual state of the federation. See the SWITCHaai Federation Metadata page for more information.

Loggers Configuration

Download the loggers configuration files shibboleth.logger, native.logger and shibd.logger and store them in /etc/shibboleth directory.

The Shibboleth SP will log in the /var/log/shibboleth directory.

Shibboleth Daemon Startup Script

The Shibboleth SP 1.3.3 daemon shibd must run in parallel with Apache.

  1. Download the Solaris shibd startup script and store it in the /etc/init.d directory.
    Content of file: /etc/init.d/shibd

    #! /bin/sh
    #set -x
    #
    # /etc/init.d/shibd for Solaris
    #
    # start/stop script for Shibboleth ServiceProvider 1.3 daemon 
    #
    # Created:  20050602 - Valery Tschopp - SWITCH
    # Modified: 20050916 - Dominique Petitpierre at adm.unige.ch: Solaris port
    #           20080108 - Valery Tschopp - SWITCH: Shibboleth 1.3.1 update
    #
    # HOWTO INSTALL: 
    # cp shibd /etc/init.d/shibd
    # chmod u+x /etc/init.d/shibd
    # cd /etc/init.d
    # ln -s shibd /etc/rcS.d/K28shibd
    # ln -s shibd /etc/rc0.d/K28shibd
    # ln -s shibd /etc/rc1.d/K28shibd
    # ln -s shibd /etc/rc2.d/K28shibd
    # ln -s shibd /etc/rc3.d/S15shibd
    #  
    
    PATH=/bin:/usr/bin:/sbin:/usr/sbin
    
    #
    # Shibboleth 1.3
    #
    SHIB_HOME=/opt/shibboleth-1.3
    SHIB_ETC=/etc/shibboleth
    
    SHIB_CONFIG=$SHIB_ETC/shibboleth.xml
    
    LD_LIBRARY_PATH=$SHIB_HOME/lib
    
    NAME=shibd
    DAEMON=$SHIB_HOME/sbin/$NAME
    DESC="Shibboleth 1.3 SP Daemon"
    
    if [ ! -x $DAEMON -o ! -f $SHIB_CONFIG ] ; then
       exit
    fi
    
    case "$1" in
      start)
        # pgrep return 0 on success
        if pgrep -f $DAEMON > /dev/null ; then 
           echo "$DESC: $NAME is already running"
        else
           echo "Starting $DESC: $NAME"
           $DAEMON -fc $SHIB_CONFIG &
           sleep 1
           if pgrep -f $DAEMON >/dev/null ; then
               :
           else
               echo "$DESC: $NAME has not started"
               exit 1
           fi
        fi  
        ;;
      stop)
        if pgrep -f $DAEMON > /dev/null ; then
            echo "Stopping $DESC: $NAME"
            pkill -x $NAME
            sleep 1
            if pgrep -x $DAEMON >/dev/null ; then
               echo "$DESC: $NAME has not stopped"
               exit 1
            fi
        else
           echo "$DESC: $NAME is not running"
        fi
        ;;
      restart)
        if $DAEMON -tc $SHIB_CONFIG >/dev/null 2>&1 ; then
            # Restart
            $0 stop
            $0 start
        else
           echo "$DESC: $NAME configuration broken, not restarting"
        fi
        ;;
      configtest)
        echo "Checking config $SHIB_CONFIG for $DESC: $NAME"
        $DAEMON -tc $SHIB_CONFIG
        echo "Done."
        ;;
      version)
        version=`$DAEMON -v`
        echo "Version of $DESC: $NAME: $version"
        ;;
      *)
        echo "Usage: - $0 {start|stop|restart|version|configtest}" >&2
        exit 1
        ;;
    esac
    
    exit 0
    

  2. Register the /etc/init.d/shibd script as a system startup script:

    root# chmod u+x /etc/init.d/shibd
    root# cd /etc/init.d
    root# ln -s shibd /etc/rcS.d/K28shibd
    root# ln -s shibd /etc/rc0.d/K28shibd
    root# ln -s shibd /etc/rc1.d/K28shibd
    root# ln -s shibd /etc/rc2.d/K28shibd
    root# ln -s shibd /etc/rc3.d/S15shibd
    

  3. Finally start the Shibboleth 1.3 Daemon:

    root# /etc/init.d/shibd start
    Starting Shibboleth 1.3 Daemon: shibd.
    

Apache Configuration

The Apache 1.3 or Apache 2.0 webserver must be configured to load and configure the Shibboleth SP 1.3 module. Your local Apache configuration could be slightly different, you should adapt the directory names regarding your installation.

Install Shibboleth Apache 1.3 Module

  1. Create the Shibboleth module configuration file mod_shib.conf and store it in the /etc/shibboleth directory.
    Content of file: /etc/shibboleth/mod_shib.conf

    ##
    # SWITCHaai 
    #
    # Shibboleth SP 1.3
    ##
    LoadModule mod_shib /opt/shibboleth-1.3/libexec/mod_shib_13.so
    
    # Shibboleth SP 1.3 config
    ShibConfig /etc/shibboleth/shibboleth.xml
    ShibSchemaDir /opt/shibboleth-1.3/share/xml/shibboleth
    
    <Files *.sso>
        SetHandler shib-handler
    </Files>
    
    ##
    # example: /aai location is protected by shibboleth
    #<Location /aai>
    #    AuthType shibboleth
    #    ShibRequireSession On
    #    require valid-user
    #</Location>
    

  2. Update the Apache 1.3 configuration file httpd.conf to include the Shibboleth module configuration file.
    Add the following line at the end of your /etc/apache/httpd.conf file:

    ...
    
    ## Shibboleth SP 1.3
    Include /etc/shibboleth/mod_shib.conf
    

  3. The Apache 1.3 webserver is normaly started with the /etc/init.d/apache script. The script must be modified and the environment variable LD_LIBRARY_PATH set to be able to load the Shibboleth module.

    You can use the sample snipet of startup script apache to correctly set the LD_LIBRARY_PATH .
    Begining of file: /etc/init.d/apache

    #!/bin/bash
    #
    # apache    Start the apache HTTP server.
    #
    # The variables below are NOT to be changed.  They are there to make the
    # script more readable.
    
    NAME=apache
    DAEMON=/usr/sbin/$NAME
    PIDFILE=/var/run/$NAME.pid
    CONF=/etc/$NAME/httpd.conf
    APACHECTL=/usr/sbin/${NAME}ctl
    # note: SSD is required only at startup of the daemon.
    SSD=`which start-stop-daemon`
    ENV="env -i LANG=C PATH=/bin:/usr/bin:/usr/local/bin"
    
    SHIB_HOME=/opt/shibboleth-1.3
    LD_LIBRARY_PATH=${SHIB_HOME}/libexec:${SHIB_HOME}/lib
    export LD_LIBRARY_PATH
    
    ...
    

  4. Finally restart your Apache 1.3 webserver:

    root# /etc/init.d/apache restart
    Restarting apache.
    

Install Shibboleth Apache 2.0 Module

  1. Download the Shibboleth module configuration mod_shib.conf and store it in the /etc/apache2/mods-available directory.
    Content of file: /etc/apache2/mods-available/mod_shib.conf

    ##
    # SWITCHaai 
    #
    # Shibboleth SP 1.3
    ##
    # Shibboleth SP 1.3 config
    ShibConfig /etc/shibboleth/shibboleth.xml
    ShibSchemaDir /opt/shibboleth-1.3/share/xml/shibboleth
    
    <Files *.sso>
        SetHandler shib-handler
    </Files>
    
    ##
    # example: /aai location is protected by shibboleth
    #<Location /aai>
    #    AuthType shibboleth
    #    ShibRequireSession On
    #    require valid-user
    #</Location>
    

  2. Download the Shibboleth module loader mod_shib.load and store it in the /etc/apache2/mods-available directory.
    Content of file: /etc/apache2/mods-available/mod_shib.load

    #
    # Load Shibboleth module for Apache2
    #
    LoadModule mod_shib /opt/shibboleth-1.3/libexec/mod_shib_20.so
    

  3. To enable the module for Apache2, it is necessary to create symlinks in the /etc/apache2/mods-enabled directory.

    root# cd /etc/apache2/mod-enabled
    root# ln -s /etc/apache2/mod-available/mod_shib.conf mod_shib.conf
    root# ln -s /etc/apache2/mod-available/mod_shib.load mod_shib.load
    

  4. The Apache 2.0 webserver is normaly started with the /etc/init.d/apache2 script. The script must be modified and the environment variable LD_LIBRARY_PATH set to be able to load the Shibboleth module.

    You can use this sample snipet startup script apache2 to correctly set the LD_LIBRARY_PATH .
    Begining of file: /etc/init.d/apache2

    #!/bin/sh -e
    #
    # apache2               This init.d script is used to start apache2.
    #                       It basically just calls apache2ctl.
    
    ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
    
    SHIB_HOME=/opt/shibboleth-1.3
    LD_LIBRARY_PATH=${SHIB_HOME}/libexec:${SHIB_HOME}/lib
    export LD_LIBRARY_PATH
    
    ...
    

  5. Finally restart your Apache 2.0 webserver:

    root# /etc/init.d/apache2 restart
    Forcing reload of web server: Apache2. 
    

AAI Resource Registry

In order to release attributes to your Service Provider the Shibboleth Identity Provider (Home Organization) needs to know all Service Providers they can communicate with. Therefore, they have to regularely update their metadata files. There is a tool called 'Resource Registry' (also see the information about the Resource Registry) whose purpose is to have an up-to date list of all Identity Provider and Service Provider in the SWITCHaai Federation.

It is vital that you register your Service Provider in the AAI Resource Registry.

To register a resource, go to the AAI Resource Registry and log in via AAI. After you are logged in, you can 'add a Resource Description'. You have to provide some technical details about your Service Provider (Resource) and then finally submit the Resource Description to the Resource Registry Authority Admin of your Home Organization. This person then has to approve your Resource before it gets active, which means that the Identity Providers receive the metadata of your Service Provider.

Protecting Resources

Protecting certain directories or pages with Shibboleth can be done via the web server or within an application itself.
Using the web server, e.g. Apache one can define rules like:

    AuthType shibboleth
    ShibRequireSession On
    ShibRequireAll On
    require affiliation student
    require homeOrganization unizh.ch ethz.ch
in the Apace configuration file or in .htaccess files.
Within an application you can access all available Shibboleth attributes as environment variables (e.g. for PHP in $_SERVER or for Perl in %ENV). This allows much more flexible authorization of users than with the web server's access rules.

You find more detailed instructions on how to protect a Resource with Shibboleth on our Shibboleth Service Provider Access Rules page.

Links

SWITCH AAI Website
http://www.switch.ch/aai/
SWITCHaai Resource Registry: Register Identity Providers and Service Providers in the SWITCHaai Federation
https://aai-rr.switch.ch
Shibboleth at Internet2
http://shibboleth.internet2.edu
Internet2 deployment guide for Shibboleth SP 1.3
http://shibboleth.internet2.edu/guides/sp/
Sun Solaris
http://www.sun.com/solaris

--
$Id: install-sp-1.3-solaris.html,v 1.24 2009/08/18 15:04:28 schnell Exp $