IIS SAML Configuration

IIS Configuration in Windows 7

  1. Start --> Control Panel --> Programs --> "Turn Windows features on or off"

  2. Select (i) IIS (ii) Web Management Tools (iii) II6 Management Compatibility (iv) IIS Management Console (v) IIS Management Scripts and Tools (vi) IIS Management Service

  3. Select (i) World Wide Web Services (ii) CGI (iii) ISAPI Filters (iv) ISAPI Extensions --> Press OK. IIS 7 Setup

  4. Test IIS to see if it is installed in your system with "" in the web browser. For our test case, we used IIS7. Test IIS

ISAPI Filter Configuration

  1. Open IIS Manager (Start --> Administrative Tools --> Internet Information Service/IIS Manager)

  2. Double click on "ISAPI and CGI Restrictions" ISAPI and CGI

  3. Add a new Filter

a. Click Actions --> Add (upper right corner)

b. Select "\opt\shibboleth-sp\lib\shibboleth\isapi_shib.dll"

c. Description: "Shibboleth"

d. Click "Allow" (from the right hand side)


e. Back to IIS Manager --> ISAPI Filters

ISAPI Filters

    1. Click "Add" (upper right corner)

    2. Filter Name: Shibboleth

    3. Executable: "\opt\shibboleth-sp\lib\shibboleth\isapi_shib.dll"


f. SSO file extension mapping

    1. Click on "Handler Mapping" from main page

SP Handler

    2. Click "Add Script Map" from Action

Script Map

    3. Request Path :".sso"

    4. Executable should be pointed to "isapi_shib.dll"


g. Restart IIS

h. Check Status

Check Status by typing in "" in the web browser. If it displays an XML document, then the Shibboleth SP Installation in Windows IIS7 in complete. Status Check

Shibboleth SP Setup in Windows 2008 R2 with IIS7

  1. Open up "Server Manager", scroll down and click on "Add Roles".

Add Role

  1. Hit "Next"


  1. Select "Web Server (IIS)", hit "Next"

Web Server

  1. Select (i) CGI

(ii) ISAPI Extensions

(iii) ISAPI Filters

(iv) Management Tools

(a) IIS Management Console

(b) IIS Management Scripts and Tools

(c) Management Service

(v) All IIS6 Management Compatibility



  1. Hit "Next", for the confirmation, check the list of plugins.


Management Tools

  1. Hit "Install" and Windows 2008 will complete the installation. A confirmation window shall appear which resembles the screenshot below.


7.Test IIS7 setup from the Internet.


Shibboleth SP 2.5.x Setup

  1. Down the Shibboleth SP 2.5.x

  2. Start the installation, keep the default path, Select "Install ISAPI modules into IIS", IIS Script Extension must be ".sso" and Hit "Next".

Shib Setup

  1. After the completion of the installation, the system will ask to reboot the system; hit "Yes".


  1. Test the Shibboleth SP installation from the SP VM using the URL "localhost/Shibboleth.sso/Status" in the address bar of the Web Browser.


Trust Relationship in IdP

  1. Create a Trust Relationship for the new SP in the IdP. It is necessary to upload the Public Certificate of the new SP in the IdP. Please note that the CN of the public certificate MUST BE the same as Hostname of the SP. Hit "Add".

Add TR

  1. Download the IdP generated configuration files for Shib SP modification.


SP Configuration

  1. The files from the IdP must be placed in the SP Configuration.

  2. Before placing them inside the SP Configuration please check

(a) The "spcert.crt" file has the CN same as the SP hostname.

(b) The "spcert.crt" and "spkey.key" has the same md5sum value.

(c) The IdP-metadata is perfectly placed inside the SP Configuration.

(d) The downloaded "shibboleth2.xml" file has values resembling the file content below.

  1. For testing purpose, we are going to protect a directory named "secure" with the IdP. Create a folder/directory in the IIS Root Directory and restart Shibd and IIS.


SSO Testing

  1. Place the following URL in the web browser: "https://SP_Name/secure"

  2. It will redirect the user to the IdP for authentication.

  3. After the authentication is complete, the user will be shown the protected page. For this case, the page is the IIS7 index page.

    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" logger="syslog.logger" clockSkew="180">

        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="https://SP_HOSTNAME/Shibboleth.sso" handlerSSL="false"
                exportLocation="http://localhost/Shibboleth.sso/GetAssertion" exportACL=""
                idpHistory="false" idpHistoryDays="7" cookieProps="; path=/; secure; httpOnly">
                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 IdPs SSO service (favoring SAML 2 over Shib 1). -->
                <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="gluu"
                        relayState="cookie" entityID="https://IDP_HOSTNAME/idp/shibboleth">
                   <SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
                   <SessionInitiator type="Shib1" acsIndex="5"/>
                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"
                <md:AssertionConsumerService Location="/SAML2/POST-SimpleSign" index="2"
                <md:AssertionConsumerService Location="/SAML2/Artifact" index="3"
                <md:AssertionConsumerService Location="/SAML2/ECP" index="4"
                <md:AssertionConsumerService Location="/SAML/POST" index="5"
                <md:AssertionConsumerService Location="/SAML/Artifact" index="6"
        <!-- 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"/>
        <!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
                <md:SingleLogoutService Location="/SLO/SOAP"
                <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
                <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
                <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
        <!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
                <md:ManageNameIDService Location="/NIM/SOAP"
                <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
                <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
                <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
                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"
        <!-- 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=""/>
                <!-- Session diagnostic service. -->
                <Handler type="Session" Location="/Session" showAttributeValues="false"/>
        Allows overriding of error template filenames. You can also add attributes with values
        that can be plugged into the templates.
        <Errors supportContact="support@gluu.org"
    <!-- Uncomment and modify to tweak settings for specific IdPs or groups. -->
    <!-- Chains together all your metadata sources. -->
        <MetadataProvider type="Chaining">
        <MetadataProvider type="XML" file="C:\opt\shibboleth-sp\etc\shibboleth\idp-metadata.xml"/>
    <!-- Chain the two built-in trust engines together. -->
        <TrustEngine type="Chaining">
                <TrustEngine type="ExplicitKey"/>
                <TrustEngine type="PKIX"/>
    <!-- Map to extract attributes from SAML assertions. -->
        <AttributeExtractor type="XML" validate="true" path="attribute-map.xml"/>
        <!-- Use a SAML query if no attributes are supplied during SSO. -->
        <AttributeResolver type="Query" subjectMatch="true"/>
        <!-- Default filtering policy for recognized attributes, lets other data pass. -->
        <AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
    <!-- Simple file-based resolver for using a single keypair. -->
        <!-- <CredentialResolver type="File" key="sp-key.pem" certificate="sp-cert.pem"/> -->
        <!-- TODO is password needed? -->
        <CredentialResolver type="File" key="C:\opt\shibboleth-sp\etc\shibboleth\spkey.key"
                        certificate="C:\opt\shibboleth-sp\etc\shibboleth\spcert.crt" />
    <!-- Each policy defines a set of rules to use to secure messages. -->
        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 type="ClientCertAuth" errorFatal="true"/>
                <PolicyRule type="XMLSigning" errorFatal="true"/>
                <PolicyRule type="SimpleSigning" errorFatal="true"/>