[Shib-Users] HTTP 401 Authorization Required returned instead of 403 Forbidden
Etienne Dysli
I'm upgrading SPs from 1.3 to 2.1 and I've noticed a change in behaviour
of mod_shib. Those SPs use lazy sessions and Apache is configured to
trap 403 errors and redirect to a login handler. As comments above the
Errors element in shibboleth2.xml say, I removed the access attribute to
cause mod_shib to return a "403 Forbidden" error. It turns out I receive
a "401 Authorization Required" error instead.
The Apache config looks like this:
<VirtualHost>
AuthType shibboleth
ShibRequireSession Off
<Directory /protected>
ErrorDocument 403 /Login.php
require entitlement intranet
</Directory>
</VirtualHost>
Why does the SP exhibit a different behaviour than the documented one?
is a bug or a misconfiguration?
Regards,
Etienne
Peter Schober
> <VirtualHost>
> AuthType shibboleth
> ShibRequireSession Off
> <Directory /protected>
> ErrorDocument 403 /Login.php
> require entitlement intranet
> </Directory>
> </VirtualHost>
According to
http://httpd.apache.org/docs/2.2/en/mod/core.html#authtype
AuthType is not valid inside the vhost.
Cheers,
-peter
--
peter....@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140
Etienne Dysli
> According to
> http://httpd.apache.org/docs/2.2/en/mod/core.html#authtype
> AuthType is not valid inside the vhost.
Thanks Peter. :) I made an error while copy-pasting the config, there is
a Location block around AuthType.
<VirtualHost>
<Location />
AuthType shibboleth
ShibRequireSession Off
</Location>
<Directory /protected>
ErrorDocument 403 /Login.php
require entitlement intranet
</Directory>
</VirtualHost>
Etienne
Peter Schober
* Etienne Dysli <etienn...@unil.ch> [2008-10-08 10:22]:
> Thanks Peter. :) I made an error while copy-pasting the config, there is
> a Location block around AuthType.
>
> <VirtualHost>
> <Location />
> AuthType shibboleth
> ShibRequireSession Off
> </Location>
> <Directory /protected>
> ErrorDocument 403 /Login.php
> require entitlement intranet
> </Directory>
> </VirtualHost>
Even taking that /protected is a filesystem path and having the
AuthType inside a <Location> this only produces HTTP 200s on a test
machine here (with accessErrror.html template in place). Also I find
the expected error about require failing both in native.log as well as
apache's error log:
[error] [client 10.0.0.1] htaccess: require entitlement not given a
valid session, are you using lazy sessions?
> Why does the SP exhibit a different behaviour than the documented
> one?
Which docs are you referring to? To me this looks like initating a
session via require and ErrorDocument directives simply won't work?
Anything wrong with just using the Location attribute from your
preferred SessionInitiator (defaults to "/Login", relative to your
handlerURL)?
Etienne Dysli
> Even taking that /protected is a filesystem path and having the
> AuthType inside a <Location> this only produces HTTP 200s on a test
> machine here (with accessErrror.html template in place).
Yes it does, provided you don't remove the "access" attribute of the
"Errors" element in your SP's shibboleth2.xml. What happens if you
remove it on your test machine?
> Which docs are you referring to?
I'm referring to the comment block above the "Errors" element in
shibboleth2.xml, which says:
"You should customize these pages! You can add attributes with values
that can be plugged into your templates. You can remove the access
attribute to cause the module to return a standard 403 Forbidden error
code if authorization fails, and then customize that condition using
your web server."
> To me this looks like initating a session via require and
> ErrorDocument directives simply won't work?
It used to work with 1.3. I fail to see why it wouldn't with 2.1...
It works if I add: ErrorDocument 401 /Login.php but I'm not sure that is
correct.
> Anything wrong with just using the Location attribute from your
> preferred SessionInitiator (defaults to "/Login", relative to your
> handlerURL)?
Sadly yes, there needs to be a PHP script inbetween that does some stuff
(I don't know exactly what, didn't write it) :/ before redirecting to
the true login handler (/Shibboleth.sso/Login).
Etienne
Peter Schober
> Yes it does, provided you don't remove the "access" attribute of the
> "Errors" element in your SP's shibboleth2.xml. What happens if you
> remove it on your test machine?
Ah, I see -- yes, same here.
> > Anything wrong with just using the Location attribute from your
> > preferred SessionInitiator (defaults to "/Login", relative to your
> > handlerURL)?
>
> Sadly yes, there needs to be a PHP script inbetween that does some
> stuff (I don't know exactly what, didn't write it) :/ before
> redirecting to the true login handler (/Shibboleth.sso/Login).
OK, so for the simple case of not needing any special logic prior to
login (whatever it is) requiring a shib session for <Directory
/proteced> would suffice -- seems there's nothing to be gained with
(direct) session initiation via ErrorDocument 401 directives (which
are mostly unworkable anyway, see
http://httpd.apache.org/docs/2.2/en/mod/core.html#errordocument so
neither /Shibboleth.sso/Login nor the full URL would work there).
Sorry for the noise, you're not any closer to the whys of s/403/401/
;)
Etienne Dysli
> OK, so for the simple case of not needing any special logic prior to
> login (whatever it is) requiring a shib session for <Directory
> /proteced> would suffice -- seems there's nothing to be gained with
Yes. Nothing to gain here, move along. ;)
In my case the obscure logic at work is here to somehow preserve request
parameters through the authentication process. So that, if an unlucky
user clicks in the webapp after his sessions has expired, he is taken
back to where he wanted to go before re-authentication. This preserves
GET request parameters, unfortunately POST parameters are lost for good.
> Sorry for the noise, you're not any closer to the whys of s/403/401/
> ;)
Erm... well.. no, I'm not. :(
Etienne
Peter Schober
> In my case the obscure logic at work is here to somehow preserve request
> parameters through the authentication process. So that, if an unlucky
> user clicks in the webapp after his sessions has expired, he is taken
> back to where he wanted to go before re-authentication. This preserves
> GET request parameters, unfortunately POST parameters are lost for
> good.
Well, for GET you should file a bug in jira IMHO, possibly for lost
POSTs as well. IIRC Scott mentioned something on the possibility of
this a while back.
Cheers,
-peter
Scott Cantor
> POSTs as well. IIRC Scott mentioned something on the possibility of
> this a while back.
GET should be preserved now unless there's a bug. POST is a different matter
(can't be done on IIS at all, and I haven't decided whether to try doing it
with Apache).
-- Scott
Scott Cantor
> is a bug or a misconfiguration?
It's something more like a bug. There's a messy history around that code because I had a lot of trouble getting all the web server APIs to handle returning HTTP-specific response codes from inside my code, and some of my attempts to get certain codes returned haven't worked in various releases, especially on Apache.
In this particular case, I think I just confused which status code to return, and it’s a trivial bug.
Reading the definitions, it's clear that 403 is what I meant to use, not least because that's what 1.3 used.
If you want to fix it ahead of me, the line is in shibsp/ServiceProvider.cpp in the sendError function at the top. Please file a bug.
-- Scott
Etienne Dysli
> If you want to fix it ahead of me, the line is in
> shibsp/ServiceProvider.cpp in the sendError function at the top.
> Please file a bug.
Thanks for the explanation Scott. :)
https://bugs.internet2.edu/jira/browse/SSPCPP-159
Etienne