Deployment of Shibboleth Service Provider (SP) 2.x on
Windows Server 2008

Authors: Brusten Philip & Ophelders Bart

Table of contents

0. Introduction

This guide describes Windows Server 2008 specific installation of a Shibboleth Service Provider 2.x and its configuration for the KULeuven Federation.
It covers installation on Windows Server 2008 with Apache 2.2.x or Microsoft IIS 7.
Note that the SP has not been extensively tested with IIS 7 yet. It seems to work, but there could well be security issues arising from internal differences in the handling of the CGI environment, custom HTTP headers, and the prevention of header spoofing. These aspects of the server tend to be undocumented and are mostly established with testing and trial and error, so for the moment, caution is advised.
In-depth information can be found at the Shibboleth Wiki from Internet2
The Shibboleth Service Provider (SP) 2.x is implemented in C/C++ as an Apache authentication module mod_shib and a separate daemon shibd.
The Shibboleth Service Provider (SP) 2.x for IIS is implemented in C/C++ as an ISAPI module isapi_shib.dll and a separate deamon shibd.

The example values used in this guide are:
$HOSTNAME
The DNS name of the Resource (Service Provider).

1. Prerequisites

Before starting to build and configure the Shibboleth Sevice Provider, assure that the following prerequisites are met:
Apache HTTP 2.2 including OpenSSL or IIS with SSL enabled.
If IIS is used, make sure IIS6 management compatibility is installed.
For download links and configuration, see references.
A proper certificate
For providing an SSL connection to the resource, a certificate is required.
The Shibboleth Service Provider also needs a certificate.
For both purposes, we will use the same commercial certificate, issued by a Certificate Authority.
(In the future, the Shibboleth Service Provider will use a self signed certificate.)
For K.U.Leuven: To request a commercial certificate, please refer to https://certificates.kuleuven.be .
NTP
Servers running Shibboleth must have their system time synchronized in order to avoid clock-skew errors:

2. Installation

Download Shibboleth Service provider from http://shibboleth.internet2.edu/downloads/shibboleth/cppsp/latest/.
Run the installation package.

Now you will be asked to accept the license agreement. After accepting the license agreement you will be shown the latest readme for this release. Press "Next" to continue.

The Shibboleth Service Provider should be installed in c:\opt\shibboleth-sp

The Shibboleth deamon is an indispensible component of the SP. It connects to the Identity Provider. For IIS, the deamon is controlled from the ISAPI module using RPC on a TCP/IP port. Using the standard port 1600 should not cause any problems. In a simple setup this is a local port that should not be accessible from any remote machine.

The ISAPI filter is the component that will be loaded by IIS to be Shibboleth-enabled, it is indispensible for IIS. The installer can configure IIS to load it on the next restart. Unfortunately the installer will only fully configure the "Default Web Site" of your ISS, but don't worry: this guide helps you to configure the others too. The file extension .sso is used to map HTTP requests to the Shibboleth ISAPI filter. You can safely tick off the checkbox if you're not using IIS since none of this applies to you in that case.

The Shibboleth Service Provider (Shibboleth Daemon, ISAPI Filter, libraries, ... ) is now fully installed at c:\opt\Shibboleth-sp\.

3. SSL certificates

As explained in the prerequisites, Shibboleth will use the same commercial certificate as the webserver.

Download the certificate the KULeuven uses for signing their metadata.
This certificate will be used to verify this metadata.
Download the certificate from http://shib.kuleuven.be/download/metadata/metadata.associatie.kuleuven.be.crt.
Put the downloaded certificate in c:\pki:

4. Configuration

4.1 shibboleth2.xml

shibboleth2.xml is the main configuration file for configuring your Shibboleth Service Provider.
Edit the c:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml file:
When using IIS, it is important too define the correct IIS Site id and hostname.
     <!-- The InProcess section conrains settings affecting web server modules/filters. -->
    <InProcess logger="native.logger">
        <ISAPI normalizeRequest="true" safeHeaderNames="true">
            <!--
            Maps IIS Instance ID values to the host scheme/name/port. 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.
            -->

            <Site id="1" name="$HOSTNAME"/>
            <!--
            When the port and scheme are omitted, the HTTP request's port and scheme are used.
            If these are wrong because of virtualization, they can be explicitly set here to
            ensure proper redirect generation.
            -->
            <!--
            <Site id="42" name="virtual.example.org" scheme="https" port="443"/>
            -->
        </ISAPI>
    </InProcess>

Configure the Requestmapper by filling in the correct $HOSTNAME and adding the redirectToSSL directive.
    <!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
    <RequestMapper type="Native">
        <RequestMap applicationId="default">
            <!--
            The example 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="$HOSTNAME" redirectToSSL="443">
                <Path name="secure" authType="shibboleth" requireSession="true"/>
            </Host>
            <!-- Example of a second vhost mapped to a different applicationId. -->
            <!--
            <Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true"/>
            -->
        </RequestMap>
    </RequestMapper>
Set the entityID: This is a unique identifier for your Service Provider. Normally it is just the URL
    <ApplicationDefaults id="default" policyId="default"
        entityID="https://$HOSTNAME"
        REMOTE_USER="eppn persistent-id targeted-id"
        signing="false" encryption="false">
Next, set some session configuration directives. Set handlerSSL and cookieProps to the correct values.
        <!--
        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 "; path=/; secure"
        in that case. Note that while we default checkAddress to "false", this has a negative
        impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
        -->
        <Sessions lifetime="28800" timeout="3600" checkAddress="false"
            handlerURL="/Shibboleth.sso" handlerSSL="true" cookieProps="; path=/; secure"
            exportLocation="http://localhost/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
            idpHistory="false" idpHistoryDays="7">
Configure the SessionInitiators. Below, two session initiators are defined. The first one will redirect the user directly to a certain IdP, defined by its entityID.
This session initiator is usefull for SP's which know to which IdP the users have to authenticate themselves.
If the SP doesn't know to which IdP the user belongs, it must redirect the user to the Discovery Service. Here the user can choose his IdP (homeorganization).
This is done in the second session initiator.
Set the appropriate isDefault value for your situation.
       <!--
            SessionInitiators handle session requests and relay them to a Discovery page,
            or to an IdP if possible. Automatic session setup will use the default or first
            element (or requireSessionWith can specify a specific id to use).
            -->

            <!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->

             <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
                    relayState="cookie" entityID="urn:mace:kuleuven.be:kulassoc:kuleuven.be">
                <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" acsIndex="6"/>
            </SessionInitiator>

            <!-- An example using an old-style WAYF, which means Shib 1 only unless an entityID is provided. -->

            <SessionInitiator type="Chaining" Location="/DS" isDefault="false" id="DS" relayState="cookie">
                <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" acsIndex="6"/>
                <SessionInitiator type="SAMLDS" URL="https://wayf.associatie.kuleuven.be/shibboleth-wayf/WAYF"/>
            </SessionInitiator> 
Customize the following pages and settings. Your users will come in contact with these if an error occurs.
        <!--
        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 supportContact="root@localhost"
            logoLocation="/shibboleth-sp/logo.jpg"
            styleSheet="/shibboleth-sp/main.css"/>
A very important step is to configure the metadata your Service Provider will use. The metadata contains information about the IdP's and SP's of your federation.
This is done by configuring Metadata Providers. Multiple Metadata Providers can be chained within the chaining Metadata Provider tags.
The example below will download the metadata from an URL and save a local copy. Checks for new metadata will be done every two hours.
The metadata will be checked for a signature with the certificate defined.
The second Metadata Provider example (commented) will simply use a local file.
       <!-- Chains together all your metadata sources. -->
        <MetadataProvider type="Chaining">
              <MetadataProvider type="XML" uri="https://shib.kuleuven.be/download/metadata/metadata-kuleuven.xml"
                 backingFilePath="metadata-kuleuven.xml" reloadInterval="7200">
               <MetadataFilter type="Signature" certificate="c:\pki\metadata.associatie.kuleuven.be.crt"/>
            </MetadataProvider>
        <!-- Example of locally maintained metadata. -->
            <!--
            <MetadataProvider type="XML" file="partner-metadata.xml"/>
            -->
        </MetadataProvider>
Service providers part of the K.U.Leuven federation will have to configure the MetadataProvider to get the metadata from https://shib.kuleuven.be/download/metadata/metadata-kuleuven.xml
For SP's part of the Association K.U.Leuven federation the URL is https://shib.kuleuven.be/download/metadata/metadata-kulassoc.xml

Attributes received from the IdP have to be mapped. This is configured in the attribute-map.
For Service Providers part of the K.U.Leuven federation or the Association K.U.Leuven federation, we have configured such an attribute-map.
Below, we configure Shibboleth to synchronize this file with https://shib.kuleuven.be/download/sp/2.x/attribute-map.xml
        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML"  uri="https://shib.kuleuven.be/download/sp/2.x/attribute-map.xml"
                 backingFilePath="attribute-map.xml" reloadInterval="7200"/>
Attributes can be filtered out by Shibboleth. These filter rules are defined in attribute-policy.xml
     <!-- Default filtering policy for recognized attributes, lets other data pass. -->
     <AttributeFilter type="XML" path="attribute-policy.xml"/>
Finally, configure the certificate and private key Shibboleth will use for encryption and signing purposes. This probabely will be the same keypair you use for your webserver.
        <!-- Simple file-based resolver for using a single keypair. -->
        <CredentialResolver type="File" key="c:\pki\$HOSTNAME.key" certificate="c:\pki\$HOSTNAME.crt"/>

The complete shibboleth2.xml file will look something like this:
    <SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    logger="syslog.logger" clockSkew="180">

    <!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
    <OutOfProcess logger="shibd.logger">
        <!--
        <Extensions>
            <Library path="odbc-store.so" fatal="true"/>
        </Extensions>
        -->
    </OutOfProcess>

    <!-- The InProcess section conrains settings affecting web server modules/filters. -->
    <InProcess logger="native.logger">
        <ISAPI normalizeRequest="true" safeHeaderNames="true">
            <!--
            Maps IIS Instance ID values to the host scheme/name/port. 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.
            -->

            <Site id="1" name="$HOSTNAME"/>
            <!--
            When the port and scheme are omitted, the HTTP request's port and scheme are used.
            If these are wrong because of virtualization, they can be explicitly set here to
            ensure proper redirect generation.
            -->
            <!--
            <Site id="42" name="virtual.example.org" scheme="https" port="443"/>
            -->
        </ISAPI>
    </InProcess>

    <!-- Only one listener can be defined, to connect in-process modules to shibd. -->
 <!-- <UnixListener address="shibd.sock"/> -->
    <TCPListener address="127.0.0.1" port="1600" acl="127.0.0.1"/>


    <!-- This set of components stores sessions and other persistent data in daemon memory. -->
    <StorageService type="Memory" id="mem" cleanupInterval="900"/>
    <SessionCache type="StorageService" StorageService="mem" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
    <ReplayCache StorageService="mem"/>
    <ArtifactMap artifactTTL="180"/>

    <!-- This set of components stores sessions and other persistent data in an ODBC database. -->
    <!--
    <StorageService type="ODBC" id="db" cleanupInterval="900">
        <ConnectionString>
        DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=shibboleth;APP=Shibboleth
        </ConnectionString>
    </StorageService>
    <SessionCache type="StorageService" StorageService="db" cacheTimeout="3600" inprocTimeout="900" cleanupInterval="900"/>
    <ReplayCache StorageService="db"/>
    <ArtifactMap StorageService="db" artifactTTL="180"/>
    -->

    <!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->

    <RequestMapper type="Native">
        <RequestMap applicationId="default">
            <!--
            The example 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="$HOSTNAME" redirectToSSL="443">
                <Path name="secure" authType="shibboleth" requireSession="true"/>
            </Host>
            <!-- Example of a second vhost mapped to a different applicationId. -->
            <!--
            <Host name="admin.example.org" applicationId="admin" authType="shibboleth" requireSession="true"/>
            -->
        </RequestMap>

    </RequestMapper>

    <!--
    The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined.
    Resource requests are mapped by the RequestMapper to an applicationId that
    points into to this section.
    -->
    <ApplicationDefaults id="default" policyId="default"
        entityID="https://$HOSTNAME"
        REMOTE_USER="eppn persistent-id targeted-id"
        signing="false" encryption="false">

        <!--
        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 "; path=/; secure"
        in that case. Note that while we default checkAddress to "false", this has a negative
        impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled.
        -->
        <Sessions lifetime="28800" timeout="3600" checkAddress="false"
            handlerURL="/Shibboleth.sso" handlerSSL="true" cookieProps ="; path=/; secure"
            exportLocation="http://localhost/Shibboleth.sso/GetAssertion" exportACL="127.0.0.1"
            idpHistory="false" idpHistoryDays="7">

            <!--
            SessionInitiators handle session requests and relay them to a Discovery page,
            or to an IdP if possible. Automatic session setup will use the default or first
            element (or requireSessionWith can specify a specific id to use).
            -->

            <!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). -->

            <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
                    relayState="cookie" entityID="urn:mace:kuleuven.be:kulassoc:kuleuven.be">
                <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" acsIndex="6"/>
            </SessionInitiator>

            <!-- An example using an old-style WAYF, which means Shib 1 only unless an entityID is provided. -->

            <SessionInitiator type="Chaining" Location="/DS" isDefault="false id="DS" relayState="cookie">
                <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" acsIndex="6"/>
                <SessionInitiator type="SAMLDS" URL="https://wayf.associatie.kuleuven.be/shibboleth-wayf/WAYF"/>
            </SessionInitiator>

            <!--
            md:AssertionConsumerService locations handle specific SSO protocol bindings,
            such as SAML 2.0 POST or SAML 1.1 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="/SAML2/POST" index="1"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"/>
            <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
            <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"/>
            <md:AssertionConsumerService Location="/SAML/POST" index="5"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>

            <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
                Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>

            <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
            <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
                <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
                <LogoutInitiator type="Local"/>
            </LogoutInitiator>

            <!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
            <md:SingleLogoutService Location="/SLO/SOAP"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

            <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
            <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

            <!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
            <md:ManageNameIDService Location="/NIM/SOAP"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
            <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
            <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>

            <!--
            md:ArtifactResolutionService locations resolve artifacts issued when using the
            SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
            -->
            <md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

            <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

            <!-- Status reporting service. -->
            <Handler type="Status" Location="/Status" acl="127.0.0.1"/>

            <!-- Session diagnostic service. -->

            <Handler type="Session" Location="/Session" showAttributeValues="false"/>

        </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 supportContact="root@localhost"
            logoLocation="/shibboleth-sp/logo.jpg"
            styleSheet="/shibboleth-sp/main.css"/>

        <!-- Uncomment and modify to tweak settings for specific IdPs or groups. -->
        <!-- <RelyingParty Name="SpecialFederation" keyName="SpecialKey"/> -->

        <!-- Chains together all your metadata sources. -->

        <MetadataProvider type="Chaining">
            <!-- Example of remotely supplied batch of signed metadata. -->

            <MetadataProvider type="XML" uri="https://shib.kuleuven.be/download/metadata/metadata-kuleuven.xml"
                 backingFilePath="metadata-kuleuven.xml" reloadInterval="7200">
                <MetadataFilter type="Signature" certificate="c:\pki\metadata.associatie.kuleuven.be.crt"/>
            </MetadataProvider>


            <!-- Example of locally maintained metadata. -->
            <!--
            <MetadataProvider type="XML" file="metadata-local.xml"/>
            -->
        </MetadataProvider>

        <!-- Chain the two built-in trust engines together. -->
        <TrustEngine type="Chaining">
            <TrustEngine type="ExplicitKey"/>
            <TrustEngine type="PKIX"/>
        </TrustEngine>

        <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" uri="https://shib.kuleuven.be/download/sp/2.x/attribute-map.xml"
                 backingFilePath="attribute-map.xml" reloadInterval="7200"/>

        <!-- Use a SAML query if no attributes are supplied during SSO. -->

        <AttributeResolver type="Query"/>

        <!-- Default filtering policy for recognized attributes, lets other data pass. -->
        <AttributeFilter type="XML" path="attribute-policy.xml"/>

        <!-- Simple file-based resolver for using a single keypair. -->
        <CredentialResolver type="File" key="c:\pki\$HOSTNAME.key" certificate="c:\pki\$HOSTNAME.crt"/>

        <!-- Example of a second application (using a second vhost) that has a different entityID. -->
        <!-- <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/> -->

    </ApplicationDefaults>

    <!-- Each policy defines a set of rules to use to secure messages. -->
    <SecurityPolicies>
        <!--
        The predefined policy enforces replay/freshness, standard
        condition processing, and permits signing and client TLS.
        -->
        <Policy id="default" validate="false">
            <PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
            <PolicyRule type="Conditions">
                <PolicyRule type="Audience"/>

                <!-- Enable Delegation rule to permit delegated access. -->
                <!-- <PolicyRule type="Delegation"/> -->
            </PolicyRule>
            <PolicyRule type="ClientCertAuth" errorFatal="true"/>
            <PolicyRule type="XMLSigning" errorFatal="true"/>
            <PolicyRule type="SimpleSigning" errorFatal="true"/>
        </Policy>
    </SecurityPolicies>

</SPConfig>
    

4.2 Attribute-policy.xml

The attribute-policy.xml file describes rules to filter out attributes or let them pass.
More information on how to set up these rules is described on https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeFilter.

4.3 Logging

There a 2 different Shibboleth related log files you can access for troubleshooting.
  • native.log: is located in c:\opt\shibboleth-sp\var\log\shibboleth\ and can be configured in c:\opt\shibboleth-sp\etc\shibboleth\native.logger
  • shibd.log: is located in c:\opt\shibboleth-sp\var\log\shibboleth\ and can be configured in c:\opt\shibboleth-sp\etc\shibboleth\shibd.logger
Make sure that the right processes have write permissions to the log files!

4.4 Layout

Shibboleth ships with some default html pages. These can be found in the C:\opt\shibboleth-sp\etc\shibboleth folder.
Modify these files to your own look and feel:
  • accessError.html
  • bindingTemplate.html
  • globalLogout.html
  • localLogout.html
  • metadataError.html
  • postTemplate.html
  • sessionError.html
  • sslError.html

5. Protect a resource

You can protect a resource with Shibboleth by configuring your webserver.

5.1 Apache HTTP webserver

Copy the apache22.config file from c:\opt\shibboleth-sp\etc\shibboleth to your ..\Apache2.2\conf\extra folder.
You can edit this file to your needs:
f.i.
    <Location /secure>
    AuthType shibboleth
    ShibRequireSession On
    require valid-user
    </Location>
More information on how to protect your resource can be found on https://spaces.internet2.edu/display/SHIB2/NativeSPhtaccess.

Include this configuration file into your main apache config file by putting the following line in your httpd.conf file, located in your ..\Apache2.2\conf folder:
    Include conf/extra/apache22.config
Also, make sure UseCanonicalName is set to On and that the ServerName is set correctly
    UsecanonicalName On
    ServerName $HOSTNAME

5.2 Microsoft IIS

Check if the Shibboleth ISAPI filter is correctly loaded:
Open IIS Manager ("Start">"Administrative Tools">"Internet Information Services (IIS) Manager")
Left click on your website. On the right, double click the "Isapi Filter" icon.
The Shibboleth ISAPI filter should be listed here.


If the Shibboleth ISAPI filter is not present, add it manually.
Name the filter "Shibboleth".
The location of the ISAPI filter dll is C:\opt\shibboleth-sp\lib\shibboleth\isapi_shib.dll.

Next, double click the "Handler mappings" icon.
Check if the .sso extension is present.

If the extension is not present, add it manually.
click on "Add Script Map"
Specify the location of the executable as C:\opt\shibboleth-sp\lib\shibboleth\isapi_shib.dll and the extension as .sso
Name it Shibboleth.

Click yes to allow the ISAPI extension.

Finally, you can start to configure the resource you want to protect.
This configuration is done in C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml
e.g.
...
	
<RequestMapper type="Native">
    <RequestMap applicationId="default">
        
...
	
	  <Host name="aai-sp101.cc.kuleuven.be" redirectToSSL="443">
            <Path name="secure" authType="shibboleth" requireSession="true"/>
	  </Host>
		  
...
	
    </RequestMap>
</RequestMapper>

...
	
More information on protecting a resource can be found on https://spaces.internet2.edu/display/SHIB2/NativeSPRequestMapper and https://spaces.internet2.edu/display/SHIB2/NativeSPXMLAccessControl.

6. Run & Test

You can test your configuration by entering the following command:
    C:\opt\shibboleth-sp\sbin>shibd -check
if the output is
    overall configuration is loadable, check console for non-fatal problems
it is alright.

Now, start the Shibboleth deamon.
Open "Start">"Administrative Tools">"Services"
Next, select the Shibboleth deamon service and click on start the service.


For testing purposes, there is the status URL https://$HOSTNAME/Shibboleth.sso/Status,
which returns information about the setup as an XML response.
For accessing the status URL, the accessing host has to be enabled in c:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml:
    ...
    <!-- Status reporting service. -->
    <Handler type="Status" Location="/Status" acl="127.0.0.1"/>
    ...

7. Firewall settings

  • inbound traffic:
    • webserver: port 80 and/or 443 are used by any browser-user
  • outbound:
    • Shibboleth daemon (shibd): has to be able to connect to every remote IdP in the federation on port 8443 for attribute fetching
    • NTP: a query from a client (like our server) is performed on a remote NTP-server that runs on port 123.

8. K.U.Leuven Shibboleth Registry

In order to fetch attributes from the Shibboleth Identity Provider, your Service Provider needs to know the location and ports.
Once you have completed your setup of the Shibboleth SP, you should mail us (shib@kuleuven.be) so we can adjust the involved metadata.

9. References