Remote IdP not responding?

[Roger Jagoda]

Scott,

Very solid analysis.


This exercise is just a test for a new client (with firewall issues, etc).
We are setting up just the barest SP for their test:


We have our entityID (under "ApplicationDefaults"):

<ApplicationDefaults
entityID="https://corpshibtest.ourcompany.com/Shibboleth.sso"
        REMOTE_USER="ShibTest" eppn persistent-id targeted-id">


We have their IdP SSO lines:

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


The local metadata from the client (sent to us because of firewall
issues, physical file in the server's file tree):

   <MetadataProvider type="XML" file="/etc/shibboleth/testdb-idp2-metadata.xml"
backingFilePath="/var/cache/shibboleth/testdb-idp2-metadata.xml"
maxRefreshDelay="86400">
   </MetadataProvider>



Some logout info:

<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>


The usual Attribute extractor:

<AttributeExtractor type="XML" validate="true" reloadChanges="false"
path="attribute-map.xml"/>


Our Sessions settings:

<Sessions lifetime="7200" timeout="3600" checkAddress="false"
relayState="ss:mem" handlerSSL="true" cookieProps="https">
</Sessions>

We do have these lines (they are in all our SPs):

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

Could they be involved in our error?

</ApplicationDefaults>


That's it. We really thought this was going to be easy. We do this
with every new SP customer so we can trap out variables, work through
IdP problems, etc.
This should be no problem, but you have seen the errors. It's a
mystery here why it is not working. The only "oddity" is that the
metaprovider is from a local file (provided by the customer). It
should still work.

The latest try (with the native.log error) was with the vhost change
in the location block:

<Location /index.php.phpinfo>
   AuthType shibboleth
   ShibRequestSetting entityID https://sso.brown.edu/idp/shibboleth
   ShibRequireSession On
   require valid-user
   ShibUseHeaders On
</Location>


(in using that we commented out the SSO entityID from the IdP point,
(which is what you picked up on):

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


In our other SPs, we will have to use the Location Block changes  as
we have the same service for many IdP sources.
But that's another thread.

We changed the above to another IdP (not supplied by local file but by
the actual <SSO> URL):


            <SSO entityID="https://shibboleth2.shidb.idp2.edu">
              SAML2 SAML1
            </SSO>

and everything works just fine.


Thoughts?


--RJ

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

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


On Wed, Jul 3, 2013 at 6:40 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> This is the error (from native.log):
>>
>> 2013-07-03 16:55:24 ERROR Shibboleth.Apache [2092] shib_check_user: No
>> default session initiator found, check configuration.
>>
>> I  know we're on the right track. Do we need to quote the
>> ShibRequestSetting arguments?
>
> No, you've mangled something in the default configuration. Just undo what you changed. You need a <SSO> element, and that's it. You've apparently removed it, and replaced it with, I guess, nothing. Otherwise I can't think how you could end up with *no* session initiator installed.
>
> I still have no clear picture what your original issue is/was. It's never been clear whether you have multiple idPs here or not. If not, then you shouldn't need to do anything special. If you do, then indeed Chris' suggestion applies, to set the IdP based on resource URL. That is not an issue unless that's the problem you need to solve.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net