Wrong metadata in relying party even if it's OK to my eyes...
Per Ejeklint
per.ejeklint at heimore.com
Fri May 4 14:37:44 BST 2012
Thank you Chad, you are correct. I had missed that there is a separate default ServerName for 443 in httpd-ssl.conf. Dang.
But now it works! :)
Per Ejeklint
Address: Heimore Group AB, Götgatan 78 22th floor, SE-118 30 Stockholm, Sweden
Phone: +4670-5090052
4 maj 2012 kl. 15:19 skrev Chad La Joie:
> What is occurring is the SP is sending an authn request that contains
> the example.com hostname. The IdP then checks its metadata (which is
> viewed as trusted, authoritative information about relying parties to
> which it communicates) to ensure that the URL given in the request
> matches the URL in the metadata and that's failing. So it's not the
> IdP pulling that incorrect URL from metadata, it's the SP giving it to
> the IdP and the IdP noticing a mismatch from what its supposed to be.
>
> So, the issue is a SP-environment issues. Specifically, your
> webserver is probably misconfigured and telling the SP that the
> hostname of the server is example.com at the time that SP is
> constructing that ACS URL.
>
> On Fri, May 4, 2012 at 9:10 AM, Per Ejeklint <per.ejeklint at heimore.com> wrote:
>> Hey world, new Shibboleth user here!
>>
>> I'm trying to set up a local installation of IdP and SP on the same machine
>> (Mac OS X Lion) and have gotten it to work - almost. I stumble upon a
>> mismatch in URLs after successfully have logged in with the configured LDAP.
>> IDP says
>>
>> WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:206] -
>> Relying party 'https://sp.ejeklint.se/shibboleth' requested the response to
>> be returned to endpoint with ACS URL
>> 'https://www.example.com/Shibboleth.sso/SAML2/POST' and binding
>> 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST' however no endpoint, with
>> that URL and using a supported binding, can be found in the relying party's
>> metadata
>>
>> and that's fair enough as "https://www.example.com..." is not a correct URL.
>> But the thing is that I share metadata ONLY through files, and in my
>> metadata file for the SP there is not a trace left of "www.example.com" - my
>> own machine name is there.
>>
>> For some reason the IdP seem to pick the ACS URL from the running SP and not
>> from the metadata file I have provided. Now I'm stuck and need a (gentle)
>> kick in the right direction.
>>
>> Here's my metadata tags in RelyingParty.xml:
>>
>> <!-- ========================================== -->
>> <!-- Metadata Configuration -->
>> <!-- ========================================== -->
>> <!-- MetadataProvider the combining other MetadataProviders -->
>> <metadata:MetadataProvider id="ShibbolethMetadata"
>> xsi:type="metadata:ChainingMetadataProvider">
>>
>> <!-- Load the IdP's own metadata. This is necessary for artifact
>> support. -->
>> <metadata:MetadataProvider id="IdPMD"
>> xsi:type="metadata:ResourceBackedMetadataProvider">
>> <metadata:MetadataResource
>> xsi:type="resource:FilesystemResource"
>> file="/opt/shibboleth-idp/metadata/idp-metadata.xml"/>
>> </metadata:MetadataProvider>
>>
>> <!-- Load the SP's metadata. -->
>> <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider"
>> xmlns="urn:mace:shibboleth:2.0:metadata" id="SPMETADATA"
>> metadataFile="/opt/shibboleth-idp/metadata/sp-metadata.xml" />
>>
>> </metadata:MetadataProvider>
>>
>> And here is the sp-metadata.xml that is referred to from RelyingParty.xml:
>>
>> <EntityDescriptor entityID="https://sp.ejeklint.se/shibboleth"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
>> <!-- The TestShib Two SP supports SAML 2.0, SAML 1.1, and Shibboleth
>> 1.2+. -->
>> <SPSSODescriptor
>> protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
>> urn:oasis:names:tc:SAML:1.1:protocol"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
>> <Extensions xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
>> <!-- Extension to permit the SP to receive IdP discovery
>> responses. -->
>> <idpdisc:DiscoveryResponse
>>
>> Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
>> Location="https://sp.ejeklint.se/Shibboleth.sso/Login"
>> index="1"
>> xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"/>
>> <idpdisc:DiscoveryResponse
>>
>> Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
>> Location="https://sp.ejeklint.se/Shibboleth.sso/Login"
>> index="2"
>> xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"/>
>> </Extensions>
>>
>> [verbose key stuff removed...]
>>
>> <!-- This tells IdPs that Single Logout is supported and
>> where/how to request it. -->
>>
>> <SingleLogoutService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SLO/SOAP"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <SingleLogoutService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
>>
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SLO/Redirect"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <SingleLogoutService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SLO/POST"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <SingleLogoutService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
>>
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SLO/Artifact"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <!-- This tells IdPs that you only need transient identifiers.
>> -->
>> <NameIDFormat
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
>> <NameIDFormat
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
>> <!--
>> This tells IdPs where and how to push assertions through the browser. Mostly
>> the SP will tell the IdP what location to use in its request, but this
>> is how the IdP validates the location and also figures out which
>> SAML version/binding to use.
>> -->
>>
>> <AssertionConsumerService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SAML2/POST"
>> index="1" isDefault="true"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <AssertionConsumerService
>>
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
>>
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SAML2/POST-SimpleSign"
>> index="2" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <AssertionConsumerService
>> Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
>>
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SAML2/Artifact"
>> index="3" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <AssertionConsumerService
>> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SAML/POST"
>> index="4" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>> <AssertionConsumerService
>> Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
>>
>> Location="https://sp.ejeklint.se/Shibboleth.sso/SAML/Artifact"
>> index="5" xmlns="urn:oasis:names:tc:SAML:2.0:metadata"/>
>>
>> <!--
>> <AttributeConsumingService index="1">
>> <ServiceName xml:lang="en">secure</ServiceName>
>> <ServiceDescription xml:lang="en">An example service that requires a
>> human-readable identifier and optional name and e-mail
>> address.</ServiceDescription>
>> </AttributeConsumingService>
>> -->
>> </SPSSODescriptor>
>>
>> <!-- This is just information about the entity in human terms. -->
>> <Organization xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
>> <OrganizationName xml:lang="en"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">Shibboleth SP at
>> ejeklint.se</OrganizationName>
>>
>> <OrganizationDisplayName xml:lang="en"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">EE SP</OrganizationDisplayName>
>>
>> <OrganizationURL xml:lang="en"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">http://www.ejeklint.se</OrganizationURL>
>> </Organization>
>> <ContactPerson contactType="technical"
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
>> <GivenName
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">Per</GivenName>
>> <SurName
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">Ejeklint</SurName>
>> <EmailAddress
>> xmlns="urn:oasis:names:tc:SAML:2.0:metadata">mailto:ejeklint at me.com</EmailAddress>
>>
>> </ContactPerson>
>>
>> </EntityDescriptor>
>>
>>
>> As for the configuration of the SP, there is indeed a problem with the
>> RequestMapper (I think). The metadata that is available
>> from https://sp.ejeklint.se/Shibboleth.sso/Metadata does indeed have the
>> wrong URLs with www.example.com in them, but as I don't have a metadata
>> provider pointing to that URL it should still work. Or am I ignorant about
>> something here? This is the RequestMapper in shibboleth2.xml which isn't
>> doing what I expect:
>>
>> <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="sp.ejeklint.se">
>> <Path name="secure" authType="shibboleth"
>> requireSession="true"/>
>> </Host>
>>
>> </RequestMap>
>> </RequestMapper>
>>
>>
>> Any ideas?
>>
>>
>> Per Ejeklint
>> Address: Heimore Group AB, Götgatan 78 22th floor, SE-118
>> 30 Stockholm, Sweden
>> Phone: +4670-5090052
>>
>>
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>
>
>
> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120504/830f982a/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4829 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/users/attachments/20120504/830f982a/attachment-0001.bin
More information about the users
mailing list