ADFS 2.0 and Shibboleth SP 2.5.3 - Unable to locate Metadata

Question

I am attempting to use Shibboleth SP (64-bit on Windows Server 2008 R2) to authenticate with ADFS 2.0 (64-bit Windows Server 2008 R2). When I browse to the Shibboleth protected site, I get a 500 error with the following in the Shibboleth native_warn log:

2014-12-08 14:44:28 ERROR Shibboleth.Listener [2648] isapi_shib: remoted message returned an error: Unable to locate metadata for identity provider (https://adfs.int.example.com/adfs/ls/)
2014-12-08 14:44:28 ERROR Shibboleth.ISAPI [2648] isapi_shib: Unable to locate metadata for identity provider (https://adfs.int.example.com/adfs/ls/)
2014-12-08 14:44:30 ERROR Shibboleth.Listener [2648] isapi_shib: remoted message returned an error: Unable to locate metadata for identity provider (https://adfs.int.example.com/adfs/ls/)
2014-12-08 14:44:30 ERROR Shibboleth.ISAPI [2648] isapi_shib: Unable to locate metadata for identity provider (https://adfs.int.example/adfs/ls/)

In the native log, it shows that the Metadata has been loaded:

2014-12-08 14:44:23 INFO OpenSAML.MetadataProvider.XML : loaded XML resource (https://adfs.int.example.com/FederationMetadata/2007-06/FederationMetadata.xml)

Here is my entire Shibboleth2.xml file:

<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"
clockSkew="180">

<!--
The InProcess section contains settings affecting web server modules.
Required for IIS, but can be removed when using other web servers.
-->
<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="iris-shib.int.example.com" scheme="https" port="443"/>
        <!--
        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>

<!--
By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
are used. See example-shibboleth2.xml for samples of explicitly configuring them.
-->

<!--
To customize behavior for specific resources on IIS, and to link vhosts or
resources to ApplicationOverride settings below, use the XML syntax below.
See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapHowTo for help.

Apache users should rely on web server options/commands in most cases, and can remove the
RequestMapper element. See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
-->
<RequestMapper type="Native">
    <RequestMap>
        <!--
        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 above.
        -->

        <Host name="iris-shib.int.example.com" 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 (or to the defaults here).
-->
<ApplicationDefaults entityID="https://iris-shib.int.example.com/shibboleth"
                     REMOTE_USER="eppn persistent-id targeted-id">

    <!--
    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. Using handlerSSL="true", the default, will force
    the protocol to be https. You should also set cookieProps to "https" for SSL-only sites.
    Note that while we default checkAddress to "false", this has a negative impact on the
    security of your site. Stealing sessions via cookie theft is much easier with this disabled.
    -->
    <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
              checkAddress="false" 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.
        -->
        <SSO entityID="https://adfs.int.example.com/adfs/ls/"
             discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
          SAML2 SAML1
        </SSO>

        <!-- 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="127.0.0.1 ::1"/>

        <!-- Session diagnostic service. -->
        <Handler type="Session" Location="/Session" showAttributeValues="false"/>

        <!-- JSON feed of discovery information. -->
        <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
    </Sessions>

    <!--
    Allows overriding of error template information/filenames. You can
    also add attributes with values that can be plugged into the templates.
    -->
    <Errors supportContact="root@localhost"
        helpLocation="/about.html"
        styleSheet="/shibboleth-sp/main.css"/>

    <!-- Example of remotely supplied batch of signed metadata. -->
    <!--
    <MetadataProvider type="XML" uri="http://federation.org/federation-metadata.xml"
          backingFilePath="federation-metadata.xml" reloadInterval="7200">
        <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
        <MetadataFilter type="Signature" certificate="fedsigner.pem"/>
    </MetadataProvider>
    -->

    <!-- Example of locally maintained metadata. -->

    <!--<MetadataProvider type="XML" file="FederationMetadata.xml"/>-->

    <MetadataProvider 
        type="XML"
        uri="https://adfs.int.example.com/FederationMetadata/2007-06/FederationMetadata.xml"
        backingFilePath="federation-metadata.xml"
        reloadInterval="7200"
    />

    <!-- Map to extract attributes from SAML assertions. -->
    <AttributeExtractor type="XML" validate="true" reloadChanges="false" 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 https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplicationOverride 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":
    -->
    <!--
    <ApplicationOverride id="admin" entityID="https://admin.example.org/shibboleth"/>
    -->
</ApplicationDefaults>

<!-- 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"/>

I've tried loading a local metadata file and I have the same results. I've also commented out both types of metadata lines, and I get the following error in the native_warn log so it seems that the metadata was actually being loaded:

2014-12-08 14:57:31 ERROR Shibboleth.Listener [2648] isapi_shib: remoted message returned an error: No MetadataProvider available.
2014-12-08 14:57:31 ERROR Shibboleth.ISAPI [2648] isapi_shib: No MetadataProvider available.

At this point, I am not sure if there is an issue with the metadata that's provided by ADFS 2.0. I can't paste it all here (due to a character limit). Is there a certain section that I should be checking?

score 3 · Accepted Answer · answered Dec 12 '14 at 19:00

3

You got the identifier uri wrong. https://adfs.int.example.com/adfs/ls/" is the endpoint. Not the identifier.

Identifier is http://adfs.int.example.com/adfs/services/trust" by default. Note its not https. But this can be changed by an admin. I don't know if you have.

You can use get-adfsproperties cmdlet or the AD FS management console to view existing identifier.

Else read the https://adfs.int.example.com/FederationMetadata/2007-06/FederationMetadata.xml metadata file to see identifier. It mentions entityID in it.

Identifier is case sensitive and must be typed exactly as its used by AD FS.

Change the

<SSO entityID="https://adfs.int.example.com/adfs/ls/"
             discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
          SAML2 SAML1
        </SSO>

to something like below once you figure out the identifier in use

<SSO entityID="http://adfs.int.example.com/adfs/services/trust"
             discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
          SAML2 SAML1
        </SSO>

answered Dec 12 '14 at 19:00

maweeras

2,674
2
16
23

Thank you for the heads up on needing to change the identifier URL to HTTPS as well. FYI for others: I changed the identifier to HTTPS in the AD FS 2.0 Management console by selecting Service in the left pane and then clicking Edit Federation Service Properties on the right. Then changed Federation Service Identifier to be HTTPS. Also, once I saved this, I also had to add the Support Contact Info in the Organization tab or Shibboleth SP threw an error. – OrangeGrover Dec 17 '14 at 01:39
Just FYI You don't need to change the identifier in AD FS to be HTTPS. You can change it to any other URI if you don't want the default value. But making it HTTPS is unnecessary. I never implied it was a required change. I merely wanted to highlight your shib config error. – maweeras Dec 17 '14 at 16:42
Is making the identifier HTTPS unnecessary from a functionality perspective, or is it also unnecessary from a security perspective as well? I am not sure what data is actually relayed using this URI. – OrangeGrover Dec 17 '14 at 19:15
completely unnecessary. the uri is used to uniquely identify this ad fs farm. – maweeras Dec 17 '14 at 23:16

ADFS 2.0 and Shibboleth SP 2.5.3 - Unable to locate Metadata

1 Answers1