[Shib-Users] None of the configured SessionInitiators handled the request - but nothing in my logs

[Jeff Silverman]

I am getting "None of the configured SessionInitiators handled the request." when I try to hit the  "/secure" Shibboleth protected area on my virtualhost. However, there is nothing at all in my shibd logs, and I have everything that I can set to DEBUG. This SP is known working with other IdPs and Apache VirtualHosts.

To start with, I'd just like some advice on getting something reported in the shibd.log. Also, I'm happy to report configuration details, but I'm not precisely sure which details I should supply.

Thank you!

--
Jeffrey D. Silverman
Systems Administrator/IT Specialist • Moodlerooms, Inc.
je...@moodlerooms.com

[Peter Schober]

* Jeff Silverman <je...@moodlerooms.com> [2010-04-17 14:28]:

> I am getting "None of the configured SessionInitiators handled the request."
> when I try to hit the "/secure" Shibboleth protected area on my
> virtualhost. However, there is nothing at all in my shibd logs, and I have
> everything that I can set to DEBUG. This SP is known working with other IdPs
> and Apache VirtualHosts.

How do you curently map SessionInitiators to content?
Native ShibRequestSetting or via the RequestMap? I would guess that there is
none for this URL and you don't have isDefault="true" on any of your
configured SessionInitiators.

> To start with, I'd just like some advice on getting something reported in
> the shibd.log. Also, I'm happy to report configuration details, but I'm not
> precisely sure which details I should supply.

https://spaces.internet2.edu/display/SHIB2/NativeSPTroubleshootingTactics
linked from https://spaces.internet2.edu/display/SHIB2/Troubleshooting
-peter


--
Subscription settings: http://groups.google.com/group/shibboleth-users/subscribe?hl=en

[Scott Cantor]

> I am getting "None of the configured SessionInitiators handled the
request."
> when I try to hit the "/secure" Shibboleth protected area on my
> virtualhost.

The cause depends a great deal on what you're configuring it to do, but the
best way to solve it is to understand in depth what they do and how they do
their work. If there's something unclear from the documentation about what
each piece of a chain is supposed to do, it would help to clarify that.

> However, there is nothing at all in my shibd logs, and I have
> everything that I can set to DEBUG.

And native.log?

> To start with, I'd just like some advice on getting something reported in
> the shibd.log.

What's there is what's there. If it's not telling you anything, then it may
be detecting the problem before it has any use for shibd.

> Also, I'm happy to report configuration details, but I'm not
> precisely sure which details I should supply.

Your SessionInitiator details would be a good start.

-- Scott

[Jeff Silverman]

Re: Green box: Sorry I should have mentioned that I did, in fact, check the ownership and directory perms to make sure the Apache user could write where it needed to. In fact, I went as far as su-ing to the webservd user and seeing if I could create a file in that directory, and I could.

I'll digest the rest of this and post more questions, I'm sure.

Thanks!

On Tue, Apr 20, 2010 at 3:27 PM, Scott Cantor <cant...@osu.edu> wrote:

>         <ApplicationOverride id="uniqueschoolname"

<snip!>

[Scott Cantor]

> Re: Green box: Sorry I should have mentioned that I did, in fact, check
the
> ownership and directory perms to make sure the Apache user could write
where
> it needed to. In fact, I went as far as su-ing to the webservd user and
> seeing if I could create a file in that directory, and I could.

Nevertheless, that's the cause. The fact that even after all that you
couldn't get the permissions exactly right is why I haven't tried to
automate it during the installation.

[Scott Cantor]

> <ApplicationOverride id="uniqueschoolname"
> entityID="https://moodle.uniqueschoolname.edu/auth/shibboleth"
>
> <Sessions lifetime="28800" timeout="3600" checkAddress="false"
> handlerURL="/Shibboleth.sso" handlerSSL="false">
> <SessionInitiator
> type="Chaining"
> Location="/Login"

All of that is inadvisable. Unless there's something different about any of
those settings in the override, they should be defaulted and shared.
Overrides for setting the entityID on a vhost basis should typically be
nothing but:

<ApplicationOverride id="uniqueschoolname"
entityID="https://moodle.uniqueschoolname.edu/auth/shibboleth"/>

Secondly, your chain is unneeded because you've put only a single element
inside it. That's usually also wrong (and is in fact your problem here).

> <SessionInitiator
> type="SAML2"
> defaultACSIndex="1"
> entityID="urn:mace:incommon:uniqueschoolname.edu"
> />

That means you will fail any time the IdP doesn't support SAML 2.0, and is
the reason the chain is simply failing to execute. You asked for it, you got
it. If you want to avoid that, assuming the IdP(s) support legacy behavior,
you need a type="Shib1" element in the chain.

Secondly, you should share a single chain across all overrides without
specifying the entityID to use, and instead put the entityID in the
RequestMap in the Host element(s) to tell it which IdP to use for that
content tree.

> 3) It looks like '/usr/local/shibboleth/var/log/httpd/native.log' as the
> default log file in native.logger. However, I have never had anything
appear
> in that file, ever, even for working Shibboleth SP setups on the same
> server.

https://spaces.internet2.edu/display/SHIB2/NativeSPTroubleshootingTactics

Read the green box.

> 4) I keep getting a "save dialog" in firefox for a file of type
"httpd/unix-
> directory". Some googling shows that this is Apache serving up a
> misconfigured DocumentRoot. But I can't seem to get Apache to spit out
> anything in its logs regarding this, errors or otherwise.

Sorry, I don't know what that's referring to.

> So, ultimately, I'd like to get some improved logging going on. I'm sure
> that'd help to start with.

You should be seeing log information now about the SAML2 handler failing to
find SAML 2.0 support for the designated IdP. Since you put that one handler
in a chain, it's logging that on INFO and not WARN, because it assumes you
have other handlers ready to take over.

[Jeff Silverman]

Thanks for your help. I've been typing this response up, bit by bit, over several days, so sorry if it sounds disjointed.

Here is some information:

1) I'm pasting the relevant Host and ApplicationOverride sections here. I sanitized the real site name for potential privacy reasons:
-----
            <Host name="moodle.uniqueschoolname.edu" applicationId="uniqueschoolname" authType="shibboleth" requireSession="true" />

        <ApplicationOverride id="uniqueschoolname"
            entityID="https://moodle.uniqueschoolname.edu/auth/shibboleth"
            >
            <Sessions lifetime="28800" timeout="3600" checkAddress="false" handlerURL="/Shibboleth.sso" handlerSSL="false">
                <SessionInitiator
                    type="Chaining"
                    Location="/Login"

                    relayState="cookie"
                    isDefault="true"
                    acsByIndex="false"
                    id="moodle.uniqueschoolname.edu-sessioninitiator"

                    >
                    <SessionInitiator
                                    type="SAML2"
                                    defaultACSIndex="1"
                                    entityID="urn:mace:incommon:uniqueschoolname.edu"
                                      />

                </SessionInitiator>
            </Sessions>
            <MetadataProvider type="Chaining">
                <MetadataProvider type="XML" path="/var/mr/shibboleth/clients/metadata/moodle.uniqueschoolname.edu.xml"/>
            </MetadataProvider>
        </ApplicationOverride>

-----

2) I have isDefault=true set for the TestShib SessionInitiator. But I have ApplicationOverrides set for "real" apps, such as the above example.



3) It looks like '/usr/local/shibboleth/var/log/httpd/native.log' as the default log file in native.logger. However, I have never had anything appear in that file, ever, even for working Shibboleth SP setups on the same server. And I know the log area is writable by the shibd process because transaction.log and shibd.log get created there. And I have everything set to DEBUG.

NOTE: I have this set up to run on a cluster of webservers, using the TCPListener to connect to a single Shibd server. Oddly, 4 out of 12 webservers do have something show up in native.log. The rest show nothing. There is no shibd process running, though, on any webserver; only the mod_shib component loaded in Apache.


4) I keep getting a "save dialog" in firefox for a file of type "httpd/unix-directory". Some googling shows that this is Apache serving up a misconfigured DocumentRoot. But I can't seem to get Apache to spit out anything in its logs regarding this, errors or otherwise.

So, ultimately, I'd like to get some improved logging going on. I'm sure that'd help to start with.

-- Regarding the documentation: I think the documentation is amazing, really -- complete, in depth, and detailed. The trouble I have reading the docs is one of terminology -- there is a lot of Shibboleth specific lingo that I do not have committed to memory. Additionally, I'd love to see more examples, as I am a learn-by-example type. But I don't have any way to resolve these issues, these are just my take on the docs.



I'll post more details as requested; one thing at a time, I suppose.

Thanks again

[Jeff Silverman]

But the permissions are, as far as I can see, exactly right. Meaning, if they were not, then I would not have been able to create files there as the webservd user -- but I can. Also, the permissions and ownerships on the boxes that work are exactly the same as on the ones that do not work.

In any case, your other tips helped immensely. Slimming down my ApplicationOverride section was very helpful, and I actually got to a place where I think I just need to work through some details with the owner of the IdP.

Thanks again.

On Tue, Apr 20, 2010 at 4:04 PM, Scott Cantor <cant...@osu.edu> wrote:

> Re: Green box: Sorry I should have mentioned that I did, in fact, check
the
> ownership and directory perms to make sure the Apache user could write
where
> it needed to. In fact, I went as far as su-ing to the webservd user and
> seeing if I could create a file in that directory, and I could.

Nevertheless, that's the cause. The fact that even after all that you
couldn't get the permissions exactly right is why I haven't tried to
automate it during the installation.

-- Scott