How to clean the SP after "shibsp::ConfigurationException"

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to clean the SP after "shibsp::ConfigurationException"

Rainer Hoerbe
I ran into a state where the SP is stuck with a shibsp::ConfigurationException at (https://samlecho2.hoerbe.at/secure/test.php) . Session initiator did not handle request for a new session, check configuration.

I did not change the configuration. The sequence to arrive at this state is to send an AuthnRequest, wait for a few minutes, and reload the Login-screen at the browser (SP 2.5.0, IdP 2.3.3).

The problem is that the SP remains in this state even across restarts. But it did reset itself over the lunch break. Is there a kind of clean-flush-purge -f command to have that effect immediately?

Regards, Rainer
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Cantor, Scott E.
On 8/20/12 11:52 AM, "Rainer Hoerbe" <[hidden email]> wrote:

>I ran into a state where the SP is stuck with a
>shibsp::ConfigurationException at
>(https://samlecho2.hoerbe.at/secure/test.php) . Session initiator did not
>handle request for a new session, check configuration.

That's the message I changed that crops up in the case where you have it
require a session, but don't provide it with either an entityID or a DS to
use, so the config is corrupt/unusable.

>I did not change the configuration.

Change it from what? The default has an entityID of
https://idp.example.org/idp/shibboleth configured, which obviously won't
work but won't cause that error either. If you mean it was working, I
don't think that's possible. About all I could think would be if you use a
DS and then the user returns from the DS without a selection made.
Handling that case while still requiring a session won't really work.

>The problem is that the SP remains in this state even across restarts.

Well, yes, the configuration is unusable.

> But it did reset itself over the lunch break. Is there a kind of
>clean-flush-purge -f command to have that effect immediately?

It can't fix itself unless the configuration is fixed. You're missing
something somewhere.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Cantor, Scott E.
On 8/20/12 12:03 PM, "Cantor, Scott" <[hidden email]> wrote:
>
>Change it from what? The default has an entityID of
>https://idp.example.org/idp/shibboleth configured, which obviously won't
>work but won't cause that error either. If you mean it was working, I
>don't think that's possible. About all I could think would be if you use a
>DS and then the user returns from the DS without a selection made.
>Handling that case while still requiring a session won't really work.

Another possible culprit could be metadata. I didn't think it would result
in that error, but if you had a situation where the entityID configured
suddenly no longer had valid metadata, but then a few minutes later does,
that might be involved.

My recollection is you just get a metadata lookup error from that though.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Rainer Hoerbe
In reply to this post by Cantor, Scott E.

Am 20.08.2012 um 18:03 schrieb "Cantor, Scott" <[hidden email]>:

>
>> I did not change the configuration.
>
> Change it from what? The default has an entityID of
> https://idp.example.org/idp/shibboleth configured, which obviously won't
> work but won't cause that error either. If you mean it was working, I
> don't think that's possible. About all I could think would be if you use a
> DS and then the user returns from the DS without a selection made.
> Handling that case while still requiring a session won't really work.

I am using a single type SAML2 SessionInitiator, so no chaining, no DS.

I did not change any relevant element in shibboleth2.xml from the previous working configuration, and did not touch or any other config file.

The strange thing is: In the error state I restored former, working versions of my shibboleth2.xml, restarted shibd with them, but the error state remained. Although I did not believe that the browser cache could be the culprit, I tried with another browser from another VM, but it has the same result.

> It can't fix itself unless the configuration is fixed. You're missing
> something somewhere.

This is what I watched, and I did not have a beer with my lunch.

So you are saying that all state is purged when restarting shibd?

- Rainer


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Cantor, Scott E.
On 8/20/12 12:21 PM, "Rainer Hoerbe" <[hidden email]> wrote:
>
>I did not change any relevant element in shibboleth2.xml from the
>previous working configuration, and did not touch or any other config
>file.

Then I would guess metadata's involved somewhere.

>The strange thing is: In the error state I restored former, working
>versions of my shibboleth2.xml, restarted shibd with them, but the error
>state remained.

That doesn't seem strange to me at all.

> Although I did not believe that the browser cache could be the culprit,
>I tried with another browser from another VM, but it has the same result.

It isn't involved.

>So you are saying that all state is purged when restarting shibd?

Yes, but I'm saying that isn't what fixed it. It's not a state-related
issue. If restarting shibd made a difference, then metadata was involved,
and I'm mistaken about the error you get in that situation. One
possibility would be that there was metadata but it was off in some way.
Maybe that affects the error that it throws.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Rainer Hoerbe
>
> Then I would guess metadata's involved somewhere.

I own the metadata and did not change it. Shibd did not detect a change either for at least 3 days:
"remote resource (http://metadata.portalverbund.at/testfed-metadata.xml) unchanged, adjusted reload interval to 7200 seconds"

>> The strange thing is: In the error state I restored former, working
>> versions of my shibboleth2.xml, restarted shibd with them, but the error
>> state remained.
>
> That doesn't seem strange to me at all.

Yes, shibboleth2.xml does not seem to be the cause, although I believe that it is the only artifact that I changed.

I will wait fro some hours if there is a timeout of either the problem or my ability to see the cause.

- Rainer
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Cantor, Scott E.
On 8/20/12 1:07 PM, "Rainer Hoerbe" <[hidden email]> wrote:

>>
>> Then I would guess metadata's involved somewhere.
>
>I own the metadata and did not change it. Shibd did not detect a change
>either for at least 3 days:
>"remote resource (http://metadata.portalverbund.at/testfed-metadata.xml)
>unchanged, adjusted reload interval to 7200 seconds"

I'm lost then. The only way you get the error is if the session initiator
chain or handler falls through without dispatching a request (if and only
if you actually require a session and there isn't one). All I did was
inject a more explicit error message for that situation.

I think you'd also have to *not* have a chain in place (and I think you
said you just explicitly configured the SAML 2 handler).

So something prevented it from successfully generate the request. Are
there any logs on either native or shibd side about it?

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How to clean the SP after "shibsp::ConfigurationException"

Rainer Hoerbe
For the records:

<SessionInitiator type="SAML2"> was missing the entityID, as Scott noted.

- Rainer

Am 20.08.2012 um 19:18 schrieb "Cantor, Scott" <[hidden email]>:

> On 8/20/12 1:07 PM, "Rainer Hoerbe" <[hidden email]> wrote:
>
>>>
>>> Then I would guess metadata's involved somewhere.
>>
>> I own the metadata and did not change it. Shibd did not detect a change
>> either for at least 3 days:
>> "remote resource (http://metadata.portalverbund.at/testfed-metadata.xml)
>> unchanged, adjusted reload interval to 7200 seconds"
>
> I'm lost then. The only way you get the error is if the session initiator
> chain or handler falls through without dispatching a request (if and only
> if you actually require a session and there isn't one). All I did was
> inject a more explicit error message for that situation.
>
> I think you'd also have to *not* have a chain in place (and I think you
> said you just explicitly configured the SAML 2 handler).
>
> So something prevented it from successfully generate the request. Are
> there any logs on either native or shibd side about it?
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]