From Koha Wiki

Jump to: navigation, search
<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
    <!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
    <ApplicationDefaults entityID="" REMOTE_USER="eppn persistent-id targeted-id">
        <!-- For AD FS, the entityID looked like this: -->
        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 defaults to /Shibboleth.sso, and should be a relative path, with the SP computing
        a relative value based on the virtual host. 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" relayState="ss:mem" handlerSSL="true" cookieProps="https">
            Configures SSO for a default IdP. To allow for >1 IdP, remove
            entityID property and adjust discoveryURL to point to discovery service.
            (Set discoveryProtocol to "WAYF" for legacy Shibboleth WAYF support.)
            You can also override entityID on /Login query string, or in RequestMap/htaccess.
            For AD FS, the entityID should be "" The http vs https is important.
            It is also recommended to remove SAML1 here unless you're sure you need it.
            <SSO entityID="">
              SAML2 SAML1
            <!-- SAML and local-only logout. -->
            <Logout>SAML2 Local</Logout>
            <!-- 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=""/> <!-- This can be usefull for debugging -->
            <!-- Session diagnostic service. -->
            <Handler type="Session" Location="/Session" showAttributeValues="false"/> <!-- Also very useful for debugging -->
            <!-- JSON feed of discovery information. -->
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
        Allows overriding of error template information/filenames. You can
        also add attributes with values that can be plugged into the templates.
        <Errors supportContact=""
        <!-- Example of remotely supplied batch of signed metadata. -->
        <MetadataProvider type="XML" uri=""
              backingFilePath="/var/cache/shibboleth/metadata/ukfederation-metadata.xml" reloadInterval="14400">
            <MetadataFilter type="RequireValidUntil" maxValidityInterval="2592000"/>
            <MetadataFilter type="Signature" certificate="ukfederation.pem"/>
        </MetadataProvider> <!-- This is a popular metadata provider used by many UK universities -->
        <!-- If you're following this guide for AD FS, comment out the previous entry and use this instead: 
	<MetadataProvider type="XML" file="/etc/shibboleth/filtered-metadata.xml"/>
        <!-- Example of locally maintained metadata. -->
        <MetadataProvider type="XML" file="partner-metadata.xml"/>
        --> <!-- If they don't have a hosted copy of the metadata, then you need a local copy -->
        <!-- 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"/>
        The default settings can be overridden by creating ApplicationOverride elements (see
        the topic).
        Resource requests are mapped by web server commands, or the RequestMapper, to an
        applicationId setting.
        Example of a second application (for a second vhost) that has a different entityID.
        Resources on the vhost would map to an applicationId of "admin" (This may be very helpful
        for providing a second entityID for the koha staff client for instance).
        This is not necessary for AD FS, but you will need to manually edit the Endpoints and Identifiers in the Relying Part Trust on your AD FS server to allow both sets of addresses.
        <ApplicationOverride id="koha-staff" entityID="" homeURL="" REMOTE_USER="eppn persistent-id targeted-id">
         <Sessions lifetime="28800" timeout="3600" checkAddress="false" relayState="ss:mem" handlerSSL="false">
           <SSO entityID="">
              SAML2 SAML1
          <AttributeExtractor type="XML" validate="true" path="koha-staff-attribute-map.xml"/>
          <MetadataProvider type="XML" file="/var/cache/shibboleth/staff-idp.xml"/>
    <!-- Policies that determine how to process and authenticate runtime messages. -->
    <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
    <!-- Low-level configuration about protocols and bindings available for use. -->
    <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>