Adfs

ADFS 2.0 和 Shibboleth SP 2.5.3 - 無法定位元數據

  • December 12, 2014

我正在嘗試使用 Shibboleth SP(Windows Server 2008 R2 上的 64 位)對 ADFS 2.0(64 位 Windows Server 2008 R2)進行身份驗證。當我瀏覽到受 Shibboleth 保護的站點時,我在 Shibboleth native_warn 日誌中收到 500 錯誤並顯示以下內容:

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/)

在本機日誌中,它顯示元數據已載入:

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

這是我的整個 Shibboleth2.xml 文件:

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

我嘗試載入本地元數據文件,結果相同。我還註釋掉了這兩種類型的元數據行,並且在 native_warn 日誌中收到以下錯誤,因此似乎元數據實際上正在載入:

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.

此時,我不確定 ADFS 2.0 提供的元數據是否存在問題。我不能在這裡全部粘貼(由於字元限制)。我應該檢查某個部分嗎?

您的標識符 uri 錯誤。https://adfs.int.example.com/adfs/ls/ “是端點。不是標識符。

預設情況下,標識符是http://adfs.int.example.com/adfs/services/trust “。注意它不是 https。但這可以由管理員更改。我不知道你是否有。

您可以使用 get-adfsproperties cmdlet 或 AD FS 管理控制台來查看現有標識符。

否則請閱讀https://adfs.int.example.com/FederationMetadata/2007-06/FederationMetadata.xml元數據文件以查看標識符。它在其中提到了 entityID。

標識符區分大小寫,並且必須完全按照 AD FS 使用的方式鍵入。

更改

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

一旦你找出正在使用的標識符,就會變成下面的樣子

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

引用自:https://serverfault.com/questions/650126