[Shib-Users] requested URL /Shibboleth.sso/Status was not found
Steven_...@brown.edu
RH 3/apache platform.
the build worked. apache and shibd start up without complaints. There
are no errors in error_log. native_log is functioning and looks fine.
Yet they're getting the above error when they access the Status
endpoint in the SP (and, obviously, that access doesn't create any
entries in native.log).
Any suggestions on what to look for? Or what to try next?
Thanks.
Scott Cantor
If it's Apache 1.3, I'd suspect maybe the handler wasn't configured for the
.sso extension.
Otherwise, no obvious ideas come to mind on Apache. I would actually suspect
mod_shib isn't even loaded. Are you sure the log indicates that it did?
-- Scott
Steven_...@brown.edu
> > Any suggestions on what to look for? Or what to try next?
>
>.sso extension.
It is 1.3. Where would that configuration be controlled?
>
>Otherwise, no obvious ideas come to mind on Apache. I would actually suspect
>mod_shib isn't even loaded. Are you sure the log indicates that it did?
>
I share that suspicion.... but, when apache is restarted, native log
seems to get new entries added to it....
actually... looking closer at last night's log... there may be problems...
2008-10-06 21:09:43 INFO Shibboleth.Config : building ListenerService
of type UnixListener...
2008-10-06 21:09:43 INFO Shibboleth.Config : building SessionCache of
type StorageService...
2008-10-06 21:09:43 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs
2008-10-06 21:09:43 INFO Shibboleth.Config : building RequestMapper
of type Native...
2008-10-06 21:09:43 INFO Shibboleth.Config : building ListenerService
of type UnixListener...
2008-10-06 21:09:43 INFO Shibboleth.Config : building SessionCache of
type StorageService...
2008-10-06 21:09:43 INFO Shibboleth.Config : building ListenerService
of type UnixListener...
2008-10-06 21:09:43 INFO Shibboleth.Config : building SessionCache of
type StorageService...
2008-10-06 21:09:43 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs
2008-10-06 21:09:43 INFO Shibboleth.Config : building RequestMapper
of type Native...
2008-10-06 21:09:43 INFO Shibboleth.Config : building ListenerService
of type UnixListener...
2008-10-06 21:09:43 INFO Shibboleth.Config : building SessionCache of
type StorageService...
2008-10-06 21:09:43 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs
2008-10-06 21:09:43 INFO Shibboleth.Config : building RequestMapper
of type Native...
2008-10-06 21:09:43 INFO Shibboleth.Config : building ListenerService
of type UnixListener...
2008-10-06 21:09:43 INFO Shibboleth.Config : building SessionCache of
type StorageService...
2008-10-06 21:09:43 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs
2008-10-06 21:09:43 INFO Shibboleth.Config : building RequestMapper
of type Native...
2008-10-06 21:09:43 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs
2008-10-06 21:09:43 INFO Shibboleth.Config : building RequestMapper
of type Native...
2008-10-06 21:10:23 INFO Shibboleth.Config : building ListenerService
of type UnixListener...
2008-10-06 21:10:23 INFO Shibboleth.Config : building SessionCache of
type StorageService...
2008-10-06 21:10:23 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs
2008-10-06 21:10:23 INFO Shibboleth.Config : building RequestMapper
of type Native...
and then it stops.....
Scott Cantor
In the apache.config snippet that shows how to load the module. In 1.3, the
handler will only run if it's installed for the file extension pattern or
unless the whole server tree is protected by at least an AuthType/require
pair.
> I share that suspicion.... but, when apache is restarted, native log
> seems to get new entries added to it....
Ok, just checking.
> actually... looking closer at last night's log... there may be problems...
Looks fine.
-- Scott
Steven_...@brown.edu
> > It is 1.3. Where would that configuration be controlled?
>
>handler will only run if it's installed for the file extension pattern
presumably that's how the handler gets triggered when the path is
Shibboleth.sso ?
sounds like perhaps this got lost, somehow, during their build process... ?
is there someplace to look, to confirm that apache should still be
seeing this, during startup?
Scott Cantor
?
There is no automatic integration with Apache in a source build, only an RPM
installation.
> is there someplace to look, to confirm that apache should still be
> seeing this, during startup?
No. Either it's part of the Apache configuration or it's not. Ordinarily I
would suggest just including the snippet provided. Perhaps somebody got
"clever" and decided they knew better about what commands were needed to
load the module.
-- Scott
Steven_...@brown.edu
> > It is 1.3. Where would that configuration be controlled?
>
>unless the whole server tree is protected by at least an AuthType/require
>pair.
>
They COPY/PASTEd the contents of shib.conf (from an RM install), and
put that into httpd.conf. (and updated the path to mod-shib).
That should be enuf, right?
Your comment above -- "it's installed for the file extension
pattern" -- made me wonder whether there's some special Directive
telling apache the mapping for the Shib file extension pattern... but
I don't remember ever seeing anything like that.....
Scott Cantor
> put that into httpd.conf. (and updated the path to mod-shib).
>
> That should be enuf, right?
Nope, not unless the RM install was for Apache 1.3.
> Your comment above -- "it's installed for the file extension
> pattern" -- made me wonder whether there's some special Directive
> telling apache the mapping for the Shib file extension pattern... but
> I don't remember ever seeing anything like that.....
There is.
<Files *.sso>
SetHandler shib-handler
</Files>
-- Scott
Randy Wiemer
canonical form of the SignedInfo element that Shibboleth 1.3 produces.
Is there any method short of inserting new code which would cause this to be
logged so that it can be reviewed?
Randy Wiemer
Oxford Computer Group
Steven_...@brown.edu
>
>> Your comment above -- "it's installed for the file extension
>> pattern" -- made me wonder whether there's some special Directive
>> telling apache the mapping for the Shib file extension pattern... but
>> I don't remember ever seeing anything like that.....
>
>
><Files *.sso>
>SetHandler shib-handler
></Files>
>
I don't remember seeing that, even in any of the files installed by
linux RPMs....
when they added it, they got:
>shibsp::ConfigurationException at
>(http://alpha.services.brown.edu/Shibboleth.sso/metadata)
>
>Shibboleth handler invoked at an unconfigured location.
so the handler is certainly there and running.... but it doesn't seem
to be recognizing Shibboleth.sso as a "special" handler?
Brent Putman
setting up DEBUG level logging minimally for package
'edu.internet2.middleware.shibboleth.idp.provider'.
I think you should see then see debug output from the
ShibbolethV1SSOHandler on debug level, with something like "Dumping
generated SAML Response:" followed by the Base64-encoded SAML Response
element.
Or if you're using the ADFS plugin, it would be "Dumping generated
Security Token Response:"
--Brent
Scott Cantor
> canonical form of the SignedInfo element that Shibboleth 1.3 produces.
>
> Is there any method short of inserting new code which would cause this to
be
> logged so that it can be reviewed?
It's logged on DEBUG in whatever class/category dumps the SAML response
during SSO. Full DEBUG will obviously capture it.
It's also sitting (base64'd) in your browser, and should be loggable by them
on their side I would think.
Of course, writing code based on something we happen to be generating today
is a big, big no-no. The XML Signature specification as profiled by SAML is
what they have to implement. Shortcuts == broken code.
-- Scott
Scott Cantor
> linux RPMs....
/etc/shibboleth/apache.config
Every install, by whatever means, will copy in three snippet files, one for
each Apache version.
> when they added it, they got:
>
> >shibsp::ConfigurationException at
> >(http://alpha.services.brown.edu/Shibboleth.sso/metadata)
> >
> >Shibboleth handler invoked at an unconfigured location.
/metadata is undefined. /Metadata is not. URLs are case sensitive.
> so the handler is certainly there and running.... but it doesn't seem
> to be recognizing Shibboleth.sso as a "special" handler?
/Shibboleth.sso isn't a Shibboleth handler, it's a signal to Apache to run
an Apache handler. Shibboleth handlers live at paths below the handlerURL
root path.
-- Scott
Steven_...@brown.edu
> > I don't remember seeing that, even in any of the files installed by
>> linux RPMs....
>
>
>Every install, by whatever means, will copy in three snippet files, one for
>each Apache version.
>
so how does the apache server find that file? I had always assumed
that apache loaded the shib.conf file that gets copied to
/etc/httpd/conf.d
Scott Cantor
> that apache loaded the shib.conf file that gets copied to
> /etc/httpd/conf.d
It doesn't find the file. Putting files into conf.d is a Red Hat specific
mechanism (sort of) that happens to work and is directly handled by the RPM
package. It's not assumed, and the config samples are all provided so that
people can see the right commands and include them however they need to.
-- Scott
Randy Wiemer
node differently from what Shibboleth is producing. They are telling me
that the SAML token in the post as well as the XML in the DEBUG log is NOT
in canonicalized form.
Is it possible to dump the actual text that Shib generates the RSA-SHA1
signature on?
Are there any OpenSAML tools that make it easy to generate this text for
debugging purposes?
Randy Wiemer
Oxford Computer Group
--------------------------------------------------
From: "Brent Putman" <put...@georgetown.edu>
Sent: Tuesday, October 07, 2008 3:27 PM
To: <shibbole...@internet2.edu>
Subject: Re: [Shib-Users] Canonical form of SignedInfo element
Scott Cantor
> node differently from what Shibboleth is producing. They are telling me
> that the SAML token in the post as well as the XML in the DEBUG log is NOT
> in canonicalized form.
I suspect that's true, yes.
> Is it possible to dump the actual text that Shib generates the RSA-SHA1
> signature on?
Not easily, but I think xmlsec has logging categories that can be tuned to
DEBUG to get at the canonicalized bytes that are digested.
> Are there any OpenSAML tools that make it easy to generate this text for
> debugging purposes?
No, OpenSAML isn't doing the c14n.
-- Scott
Brent Putman
Scott Cantor wrote:
The MS Live ID folks believe their code is canonicalizing the Signedinfo node differently from what Shibboleth is producing. They are telling me that the SAML token in the post as well as the XML in the DEBUG log is NOT in canonicalized form.
I suspect that's true, yes.
And just to clarify: are they expecting (or were you) that it would be in canonicalized form? Because it typically wouldn't be. Don't confuse canonicalizing the data that is then signed, with actually replacing the signed document in the SAML binding with its canonicalized version. We don't do the latter, it's not necessary, and certainly shouldn't be expected.
Is it possible to dump the actual text that Shib generates the RSA-SHA1 signature on?
Not easily, but I think xmlsec has logging categories that can be tuned to DEBUG to get at the canonicalized bytes that are digested.
Java xmlsec does support that now, but I believe that DEBUG logging of that data to be signed only came in earlier this year, in xmlsec 1.4.2. You're using Shib 1.3, which as far as I can tell was shipping with xmlsec 1.2.1. So it's way too old to have that support.
Randy Wiemer
Randy Wiemer
Scott Cantor
> although when I asked about this on this list last week it was suggested
> that the canonicalized form might be present in the Shib logs or in base64
> in the browser - at least that was how I read your answers.
No, that wasn't what I was attempting to say. I just meant that the XML that
the other end would be seeing would be there.
> So, do you know of any practical approaches to debugging XML signature
> validation problems across different implementations?
With great pain. When we have good reason to know that it's the fault of
another implementation, the practical approach is to focus on the broken
code, not the code that works.
> Having the
> canonicalized form of the signedinfo would be extremely useful in
> determining where things are breaking but in its absence is there anything
> specific to look for?
No, not really. But what you need to know is what *they're* digesting.
Somebody can usually tell from that what the problem is with a rough idea
what the canonical form is.
-- Scott