Shibboleth2.xml - internal use skeleton: Difference between revisions

From RavenWiki
Jump to navigationJump to search
(Restore <CredentialResolver...> to use default key/cert)
No edit summary
 
(20 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The main configuration for the Shibboleth SP is a file called shibbileth2.xml. You'll find this in the main Shibboleth configuration directory whose location varies from installation to installation. Try /etc/shibboleth, /opt/shibboleth-sp/etc/shibboleth, C:\opt\shibboleth-sp\etc\shibboleth or similar.
{{New Docs}}


The following skeleton is suitable for use with an SP that only wants to work within the University and only wants to authenticate Raven users. Search it for all occurrences of 'FIX-ME' and apply the edits described in the adjacent comments. The configuration assumes a copy of the [['Ucam Federation' IdP metadata]] is available in a file called ucamfederation-idp-metadata.xml in the same directory, and will require access to a RSA key and corresponding certificate.
== Shibboleth SP v3 (and IdP v3) ==


Be careful not to corrupt or reformat this file when extracting it from this page - wikis are not the best vehicle for software distribution - or when editing it. Try not to disturb anything you are not explicitly told to alter. You can check it for major mistakes by running
These pages are being updated as (limited) time allows.


  <some path>/shibd -t (Unix)
This page on the Shibboleth.net Wiki seems to be useful : https://wiki.shibboleth.net/confluence/display/SP3/UpgradingFromV2
  <some path>\shibd.exe -check (Windows)


Where you will find shibd varies from installation to installation - try /sbin, /opt/shibboleth-sp/sbin, C:\opt\shibboleth-sp\sbin or similar.
The following file /should/ be a starting point for the shibboleth2.xml file required by an SP. Note that the filename "shibboleth2.xml" is still correct.


<pre><nowiki>
[[ shibboleth2.xml-UCAMSKEL-3 ]]
<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">


    <!-- shibboleth2.xml for use with the University of Cambridge IdP -->
There are three known changes your Authors suggest be made to the above xml file from previous versions:
    <!-- Version 2.0 2008-02-25 -->


    <!-- The OutOfProcess section contains properties affecting the shibd daemon. -->
1. In the "<nowiki><!-- Metadata provider --></nowiki>" block, The "shib2 idp" metadata should now be
    <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">
            <!--
            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.
            -->
            <Site id="1" name="sp.example.org"/>
        </ISAPI>
    </InProcess>


    <!-- Only one listener can be defined, to connect in process modules to shibd. -->
uri="https://shib.raven.cam.ac.uk/ucamfederation-sp-metadata.xml"
    <!-- FIX-ME - remove the comment markers from the beggining and end of  -->
    <!-- ONE of the following lines - from the first one for a Unix        -->
    <!-- install, from the second one for a Windows install                -->
    <!-- <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. -->
2, 3. follow the instructions at https://wiki.shibboleth.net/confluence/display/SP3/UpgradingFromV2 for "namespace" and "review all "MetadataProvider" elements in the shibboleth2.xml file for "file" and "uri" attributes".
    <!--
    <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. -->
- we believe we have done this in the above linked file, but please do check and report back if we've missed something.
    <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.
            -->
            <!-- Replace FIX-ME with the hostname of the server or virtual  -->
            <!-- host you want to protect e.g. sp.example.org              -->
            <Host name="FIX-ME">
                <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>


    <!--
== **DEPRECATED** Shibboleth SP v2 (along with the old Shibboleth V2 IdP) **DEPRECATED** ==
    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.
    -->
    <!-- Replace FIX-ME1 with the entityID of this site                    -->
    <!-- e.g. https://sp.example.org/shibboleth                            -->
    <!-- Replace FIX-ME2 with the URL of a page users could usefull be      -->
    <!-- sent to after authenticating in default of anything else. The      -->
    <!-- homepage would probably be a good choice.                          -->
    <!-- e.g. https://sp.example.org/index.html                            -->
    <ApplicationDefaults id="default" policyId="default"
        entityID="FIX-ME1"
        homeURL="FIX-ME2"
        REMOTE_USER="eppn persistent-id targeted-id"
        signing="false" encryption="false"
        >


        <!--
The main configuration for the Shibboleth SP is a file called shibboleth2.xml. You'll find this in the main Shibboleth configuration directory whose location varies from installation to installation. Try /etc/shibboleth, /opt/shibboleth-sp/etc/shibboleth, C:\opt\shibboleth-sp\etc\shibboleth or similar.
        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="false"
            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). -->
Various skeleton versions of this file are available, suitable for use with an SP that only wants to work within the University and only wants to authenticate Raven users.  
            <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
                    relayState="cookie" entityID="https://shib.raven.cam.ac.uk/shibboleth">
                <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" defaultACSIndex="5"/>
            </SessionInitiator>


            <!-- An example using an old-style WAYF, which means Shib 1 only unless an entityID is provided. -->
This one is believed to work with versions 2.3 and 2.4 of the SP software:
            <SessionInitiator type="Chaining" Location="/WAYF" id="WAYF" relayState="cookie">
                <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" defaultACSIndex="5"/>
                <SessionInitiator type="WAYF" defaultACSIndex="5" URL="https://wayf.example.org/WAYF"/>
            </SessionInitiator>


            <!-- An example supporting the new-style of discovery service. -->
**DEPRECATED** http://raven.cam.ac.uk/project/shibboleth/files/config/shibboleth2.xml-UCAMSKEL
            <SessionInitiator type="Chaining" Location="/DS" id="DS" relayState="cookie">
                <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>
                <SessionInitiator type="Shib1" defaultACSIndex="5"/>
                <SessionInitiator type="SAMLDS" URL="https://ds.example.org/DS"/>
            </SessionInitiator>


            <!--
Version 2.4 of the SP software introduced a number of simplifications to the configuration file, and version 2.5 of the software no longer accepts some features that used to work in version 2.4. This skeleton files is recommended for use with versions 2.4 and 2.5 of the SP software:
            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. -->
**DEPRECATED ** http://raven.cam.ac.uk/project/shibboleth/files/config/shibboleth2.xml-UCAMSKEL-2.5
            <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. -->
Make a copy of it and rename it shibboleth2.xml. Search it for all occurrences of 'FIX-ME' and apply the edits described in the adjacent comments. Try not to disturb anything you are not explicitly told to alter - see [[Editing XML]] for tips on editing XML files. You can check it for major mistakes by running
            <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. -->
  <some path>/shibd -t (Unix)
            <md:ManageNameIDService Location="/NIM/SOAP"
  <some path>\shibd.exe -check (Windows)
                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.
        -->
        <!-- Replace FIX-ME with a support email address that can be        -->
        <!-- displayed in error messages                                    -->
        <Errors session="sessionError.html"
            metadata="metadataError.html"
            access="accessError.html"
            ssl="sslError.html"
            localLogout="localLogout.html"
            globalLogout="globalLogout.html"
            supportContact="FIX-ME"
            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">
                <MetadataProvider type="XML" file="ucamfederation-idp-metadata.xml"/>
            <!-- Example of remotely supplied batch of signed metadata. -->
            <!--
            <MetadataProvider type="XML" uri="http://federation.org/federation-metadata.xml"
                backingFilePath="federation-metadata.xml" reloadInterval="7200">
              <SignatureMetadataFilter certificate="fedsigner.pem"/>
            </MetadataProvider>
            -->
 
            <!-- Example of locally maintained metadata. -->
            <!--
            <MetadataProvider type="XML" file="partner-metadata.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" path="attribute-map.xml"/>
       
        <!-- 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="sp-key.pem" certificate="sp-cert.pem"/>
 
        <!-- 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 and permits signing and client TLS. -->
        <Policy id="default" validate="false">
            <Rule type="MessageFlow" checkReplay="true" expires="60"/>
            <Rule type="ClientCertAuth" errorFatal="true"/>
            <Rule type="XMLSigning" errorFatal="true"/>
            <Rule type="SimpleSigning" errorFatal="true"/>
        </Policy>
    </SecurityPolicies>


</SPConfig>
The path to shibd varies from installation to installation - try /sbin, /opt/shibboleth-sp/sbin, C:\opt\shibboleth-sp\sbin or similar.
</nowiki></pre>

Latest revision as of 11:42, 3 March 2020

We're working on improving Raven resources for developers and site operators.

Try out the new Raven documentation for size.

Shibboleth SP v3 (and IdP v3)

These pages are being updated as (limited) time allows.

This page on the Shibboleth.net Wiki seems to be useful : https://wiki.shibboleth.net/confluence/display/SP3/UpgradingFromV2

The following file /should/ be a starting point for the shibboleth2.xml file required by an SP. Note that the filename "shibboleth2.xml" is still correct. 

shibboleth2.xml-UCAMSKEL-3

There are three known changes your Authors suggest be made to the above xml file from previous versions:

1. In the "<!-- Metadata provider -->" block, The "shib2 idp" metadata should now be

uri="https://shib.raven.cam.ac.uk/ucamfederation-sp-metadata.xml"

2, 3. follow the instructions at https://wiki.shibboleth.net/confluence/display/SP3/UpgradingFromV2 for "namespace" and "review all "MetadataProvider" elements in the shibboleth2.xml file for "file" and "uri" attributes".

- we believe we have done this in the above linked file, but please do check and report back if we've missed something.

**DEPRECATED** Shibboleth SP v2 (along with the old Shibboleth V2 IdP) **DEPRECATED**

The main configuration for the Shibboleth SP is a file called shibboleth2.xml. You'll find this in the main Shibboleth configuration directory whose location varies from installation to installation. Try /etc/shibboleth, /opt/shibboleth-sp/etc/shibboleth, C:\opt\shibboleth-sp\etc\shibboleth or similar.

Various skeleton versions of this file are available, suitable for use with an SP that only wants to work within the University and only wants to authenticate Raven users.

This one is believed to work with versions 2.3 and 2.4 of the SP software: 

**DEPRECATED** http://raven.cam.ac.uk/project/shibboleth/files/config/shibboleth2.xml-UCAMSKEL

Version 2.4 of the SP software introduced a number of simplifications to the configuration file, and version 2.5 of the software no longer accepts some features that used to work in version 2.4. This skeleton files is recommended for use with versions 2.4 and 2.5 of the SP software: 

**DEPRECATED ** http://raven.cam.ac.uk/project/shibboleth/files/config/shibboleth2.xml-UCAMSKEL-2.5

Make a copy of it and rename it shibboleth2.xml. Search it for all occurrences of 'FIX-ME' and apply the edits described in the adjacent comments. Try not to disturb anything you are not explicitly told to alter - see Editing XML for tips on editing XML files. You can check it for major mistakes by running 

 <some path>/shibd -t (Unix)
 <some path>\shibd.exe -check (Windows)

The path to shibd varies from installation to installation - try /sbin, /opt/shibboleth-sp/sbin, C:\opt\shibboleth-sp\sbin or similar.

Retrieved from "https://wiki.cam.ac.uk/wiki/raven/index.php?title=Shibboleth2.xml_-_internal_use_skeleton&oldid=2927"