Remote IdP not responding?

[Roger Jagoda]

Scott,

An update: It turns out that the client's IdP has a firewall rule that
prevents access to/from our SP. Go figure.
They are in the process of working that out. In the meantime, we have
two issue to work through:

1) They sent us the proper metadata file by encrypted mail. If we are
using SOLELY their metadata file, do we even need to have a
MetadataProvider URI specified?

Until we discovered the fire wall problem, we were consistently seeing
this error:

2013-07-01 11:50:23 WARN Shibboleth.SessionInitiator.SAML2 [1]: unable
to locate metadata for provider (https://shibboleth.testdb.idp2.edu)


And of course that makes sense as we had these lines for the Provider:

   <MetadataProvider type="Chaining">
        <MetadataProvider type="XML"  uri="https://shibboleth.testdb.idp2.edu"


Instead can we get away with just this:

<MetadataProvider type="XML" file="testdb.idp2.edu-metadata.xml"/>

If so, where will Shibd want that file to be located? Our guess is
/etc/shibboleth but I don't see any documentation for that location.
Does the actual fine name matter, or do we have control over that?


2) Looking through the Metadata file they sent, we see another problem/issue:

We had this for the SSO entityID:

          <SSO entityID="https://shibboleth.testdb.idp2.edu">
              SAML2 SAML1
            </SSO>


However, the Metadata file shows this for a SSO Redirect:

                <SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"

Location="https://shibboleth.testdb.idp2.edu/idp/profile/SAML2/Redirect/SSO"
/>
                 </IDPSSODescriptor>


Should the SSO entityID then be this:

            <SSO
entityID="https://shibboleth.testdb.idp2.edu/idp/profile/SAML2/Redirect/SSO">
              SAML2 SAML1
            </SSO>


For this to all work, should the local MetadataProvider stanza come
before any other of the other stanzas?
If not, how would the parser know about the local file as the MetadataProvider?


--R

====================================

Roger Jagoda
rberryj3 at gmail.com
==============================================


On Thu, Jun 27, 2013 at 9:39 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 6/27/13 7:13 PM, "Roger Jagoda" <rberryj3 at gmail.com> wrote:
>>However, when we try a protected page from our SP server, we see these
>>errors:
>>
>>shibd.log:
>
> Yes, but that has nothing to do with the metadata error itself, what does
> the relevant part of the log say?
>
>>>
>>         backingFilePath="/tmp/shibboleth/testdb.idp2-metadat.xml"
>
> It's a fairly bad idea to use /tmp for that. Or anything else really that
> needs to last more than 5 minutes. Let the system generate the path, don't
> specify one.
>
>>Just in case, we added the local MetaFile that we were able to
>>download from any browser:
>>
>>        <MetadataProvider type="XML"
>>file="/tmp/shibboleth/testdb.idp2-metadat.xm"/>
>
> Do NOT do that, you don't want duplicate metadata. If the file were even
> there, it would work, so I suppose it's not. Or it's incorrect metadata at
> the source and isn't valid, or maybe even with something loaded, the
> entityID in use isn't what's in the metadata.
>
>>The REALLY stange thing is that we can use CURL and still access the
>>remote meta from the SP Server itself:
>
> If I were taking a wild guess, it would be that you're on Red Hat 6 and
> don't have the custom libcurl in place and in use, but that's guessing.
> The log will tell you what the problem is.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net