[Shib-Users] [AUTH_TYPE] => shibboleth

195 views
Skip to first unread message

Tommy Peterson

unread,
Jun 8, 2011, 10:21:42 AM6/8/11
to shibbole...@internet2.edu

When I authenticate with shibboleth sometimes I see all the attributes released, -ID , Shib-Session-ID , Shib-Identity-Provider, Shib-Authentication-Instant , Shib-Authentication-Method , Shib-AuthnContext-Class, Shib-Session-Index , and  [AUTH_TYPE] => shibboleth.

 

But, sometimes, I see the attributes and the Application-ID , Shib-Session-ID , Shib-Identity-Provider, Shib-Authentication-Instant , Shib-Authentication-Method , Shib-AuthnContext-Class, Shib-Session-Index but no AUTH_TYPE=>shibboleth (or equals to anything for that matter—I don’t even see the AUTH_TYPE variable)?

 

Why? Is this Apache’s way of saying I have not been authenticated? If so why does Shibboleth release the attributes and the server set the other variables?

 

Thanks.



This message contains Devin Group confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail in error and delete this e-mail from your system. E-mail transmissions cannot be guaranteed secure, error-free and information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. The sender therefore does not accept liability for errors or omissions in the contents of this message which may arise as result of transmission. If verification is required please request hard-copy version.

Cantor, Scott E.

unread,
Jun 8, 2011, 10:51:14 AM6/8/11
to shibbole...@internet2.edu
On 6/8/11 10:21 AM, "Tommy Peterson" <Tommy.P...@xpandcorp.com> wrote:
>But, sometimes, I see the attributes and the Application-ID ,
>Shib-Session-ID , Shib-Identity-Provider, Shib-Authentication-Instant ,
>Shib-Authentication-Method , Shib-AuthnContext-Class, Shib-Session-Index
>but no AUTH_TYPE=>shibboleth
> (or equals to anything for that matter‹I don¹t even see the AUTH_TYPE
>variable)?

I don't pay a lot of attention to AuthType, but AFAIK that isn't possible
unless there's a bug in the layer behind Apache.

>
>Why? Is this Apache¹s way of saying I have not been authenticated? If so
>why does Shibboleth release the attributes and the server set the other
>variables?

The value should be whatever the AuthType command is set to (possibly
lower-cased, but otherwise just echoed back). It's used in part to
determine whether the SP even looks at the request, and since it has to be
set appropriately for that to happen, logically what you're describing
shouldn't happen.

-- Scott

Tommy Peterson

unread,
Jun 8, 2011, 3:57:16 PM6/8/11
to shibbole...@internet2.edu
Well it isn't. And this is related to the redirect discussion yesterday.

After playing around with things today I am still puzzled as to why this won't work.

Yes I know that all the pages are hitting index.php. I know that a rewrite of the URL is going on. I think that they are being redirected but I am not for sure.

Now the Shibboleth session header is showing up if I try to access a sub-section of the site but I am not logged in.

If I use <Location /Drupal> (the main site directory) I am fine. All works. I can click around the site and still be logged in. If I use <LocationMatch "findwork"> (which relates to a subsection of the site I am asked to log in to shibboleth, I am authenticated, and the header set (see below). The only difference between the headers for each directive usage is that if I am not using /Drupal I do not get AUTH_TYPE->shibboleth. Also, if I use <LocationMatch "findwork"> and click around the page I lose the session. You can see them below.

All traffic is sent to index.php but the pages are loaded via GET string attached. You can see that in the headings. So if it hits index.php to begin with no matter what page I am trying to hit why won't it just set the session, set AUTH_TYPE=>shibboleth and be done with it, as you said yesterday (you said: It's unusual for a request to cause a login redirect but not be processed, and virtually impossible if the rules are expressed with Apache commands.) But you also said "mod_shib processed in general every subrequest, so if the final subrequest moves the request out of the URL space it's told to process then it won't do anything for those requests.")". It hasn't moved. It is still sitting there with index.php.

Brent said " I'm not 100% sure then regarding what the final subrequest is, but it sounds like that might in fact be a problem. . . . I don't know what 'drupal_environment_initialize()' does, but clearly what's actually being invoked is /index.php.". I looked up Drupal_environment_initialize() in the API and it just creates the get string. But http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal_environment_initialize/7

There is a .htaccess file sitting in /Drupal. I pasted it below that has the modrewrite in it. Nothing special.

I am missing something and after looking at this again today I can't see it.

--Tommy

If I use:
<Location /drupal>
AuthType shibboleth
ShibRequireSession On
ShibUseHeaders On
Require shibboleth
</Location>


Array ( [OPENSSL_CONF] => ../../conf/openssl.cnf [SSLEAY_CONF] => ../../conf/openssl.cnf [Shib-Application-ID] => default [Shib-Session-ID] => _1c672d35c00b5005f49f6000fb382ada [Shib-Identity-Provider] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [Shib-Authentication-Instant] => 2011-06-08T19:03:41.443Z [Shib-Authentication-Method] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [Shib-AuthnContext-Class] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [Shib-Session-Index] => bbbbde5abb538fadd5fd1bf06dc72dd56abf099606fdf70a58fb7e67cb41f43a [address] => 12354 Main Street Suite 330 [city] => Sterling [country] => US [cphone] => 4085551212 [fname] => Tommy [lname] => Peterson [mail] => bl...@something.com[name] => tommytest [pass] => e06b00d698892623960f9d46efb29533 [transientID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [wphone] => 4085551212 [HTTP_HOST] => rt-hvcp1-test.hvcp.local [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5 [HTTP_ACCEPT_ENCODING] => gzip, deflate [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7 [HTTP_KEEP_ALIVE] => 115 [HTTP_CONNECTION] => keep-alive [HTTP_REFERER] => http://rt-hvcp1-test.hvcp.local/drupal/findwork [HTTP_COOKIE] => _shibsession_64656661756c7468747470733a2f2f72742d68766370312d746573742e687663702e6c6f63616c2f6d6f6f646c65=_1c672d35c00b5005f49f6000fb382ada; SESS492c5bf24be32ee326896d01b447e0b8=03dstpumo80nb88712b7kaq434; has_js=1 [HTTP_IF_MODIFIED_SINCE] => Wed, 08 Jun 2011 19:03:41 GMT [HTTP_SHIB_SESSION_ID] => _1c672d35c00b5005f49f6000fb382ada [HTTP_SHIB_SESSION_INDEX] => bbbbde5abb538fadd5fd1bf06dc72dd56abf099606fdf70a58fb7e67cb41f43a [HTTP_SHIB_IDENTITY_PROVIDER] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [HTTP_SHIB_AUTHENTICATION_METHOD] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [HTTP_SHIB_AUTHENTICATION_INSTANT] => 2011-06-08T19:03:41.443Z [HTTP_SHIB_AUTHNCONTEXT_CLASS] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [HTTP_SHIB_AUTHNCONTEXT_DECL] => [HTTP_SHIB_ASSERTION_COUNT] => [HTTP_NAME] => tommytest [HTTP_PASS] => e06b00d698892623960f9d46efb29533 [HTTP_FNAME] => Tommy [HTTP_LNAME] => Peterson [HTTP_ADDRESS] => 12354 Main Street Suite 330 [HTTP_CITY] => Sterling [HTTP_COUNTRY] => US [HTTP_DESCRIPTION] => [HTTP_WEBPAGE] => [HTTP_WPHONE] => 4085551212 [HTTP_CPHONE] => 4085551212 [HTTP_MAIL] => bl...@something.com[HTTP_LANGUAGE] => [HTTP_UNITID] => [HTTP_TRANSIENTID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [HTTP_PERSISTENTID] => [HTTP_SHIB_APPLICATION_ID] => default [HTTP_REMOTE_USER] => [PATH] => /sbin:/bin:/usr/sbin:/usr/bin [SERVER_SIGNATURE] =>
Apache/2.2.15 (Red Hat) Server at rt-hvcp1-test.hvcp.local Port 80
[SERVER_SOFTWARE] => Apache/2.2.15 (Red Hat) [SERVER_NAME] => rt-hvcp1-test.hvcp.local [SERVER_ADDR] => 172.16.1.84 [SERVER_PORT] => 80 [REMOTE_ADDR] => 172.16.1.15 [DOCUMENT_ROOT] => /var/www/html [SERVER_ADMIN] => root@localhost [SCRIPT_FILENAME] => /var/www/html/drupal/index.php [REMOTE_PORT] => 16766 [AUTH_TYPE] => shibboleth [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => [REQUEST_URI] => /drupal/ [SCRIPT_NAME] => /drupal/index.php [PHP_SELF] => /drupal/index.php [REQUEST_TIME] => 1307560048 )

Click on another link on the site:

Array ( [REDIRECT_OPENSSL_CONF] => ../../conf/openssl.cnf [REDIRECT_SSLEAY_CONF] => ../../conf/openssl.cnf [REDIRECT_Shib-Application-ID] => default [REDIRECT_Shib-Session-ID] => _1c672d35c00b5005f49f6000fb382ada [REDIRECT_Shib-Identity-Provider] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [REDIRECT_Shib-Authentication-Instant] => 2011-06-08T19:03:41.443Z [REDIRECT_Shib-Authentication-Method] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [REDIRECT_Shib-AuthnContext-Class] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [REDIRECT_Shib-Session-Index] => bbbbde5abb538fadd5fd1bf06dc72dd56abf099606fdf70a58fb7e67cb41f43a [REDIRECT_address] => 12354 Main Street Suite 330 [REDIRECT_city] => Sterling [REDIRECT_country] => US [REDIRECT_cphone] => 4085551212 [REDIRECT_fname] => Tommy [REDIRECT_lname] => Peterson [REDIRECT_mail] => bl...@something.com[REDIRECT_name] => tommytest [REDIRECT_pass] => e06b00d698892623960f9d46efb29533 [REDIRECT_transientID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [REDIRECT_wphone] => 4085551212 [REDIRECT_STATUS] => 200 [OPENSSL_CONF] => ../../conf/openssl.cnf [SSLEAY_CONF] => ../../conf/openssl.cnf [Shib-Application-ID] => default [Shib-Session-ID] => _1c672d35c00b5005f49f6000fb382ada [Shib-Identity-Provider] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [Shib-Authentication-Instant] => 2011-06-08T19:03:41.443Z [Shib-Authentication-Method] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [Shib-AuthnContext-Class] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [Shib-Session-Index] => bbbbde5abb538fadd5fd1bf06dc72dd56abf099606fdf70a58fb7e67cb41f43a [address] => 12354 Main Street Suite 330 [city] => Sterling [country] => US [cphone] => 4085551212 [fname] => Tommy [lname] => Peterson [mail] => bl...@something.com[name] => tommytest [pass] => e06b00d698892623960f9d46efb29533 [transientID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [wphone] => 4085551212 [HTTP_HOST] => rt-hvcp1-test.hvcp.local [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5 [HTTP_ACCEPT_ENCODING] => gzip, deflate [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7 [HTTP_KEEP_ALIVE] => 115 [HTTP_CONNECTION] => keep-alive [HTTP_REFERER] => http://rt-hvcp1-test.hvcp.local/drupal/ [HTTP_COOKIE] => _shibsession_64656661756c7468747470733a2f2f72742d68766370312d746573742e687663702e6c6f63616c2f6d6f6f646c65=_1c672d35c00b5005f49f6000fb382ada; SESS492c5bf24be32ee326896d01b447e0b8=03dstpumo80nb88712b7kaq434; has_js=1 [HTTP_IF_MODIFIED_SINCE] => Wed, 08 Jun 2011 19:03:47 GMT [HTTP_CACHE_CONTROL] => max-age=0 [HTTP_SHIB_SESSION_ID] => _1c672d35c00b5005f49f6000fb382ada [HTTP_SHIB_SESSION_INDEX] => bbbbde5abb538fadd5fd1bf06dc72dd56abf099606fdf70a58fb7e67cb41f43a [HTTP_SHIB_IDENTITY_PROVIDER] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [HTTP_SHIB_AUTHENTICATION_METHOD] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [HTTP_SHIB_AUTHENTICATION_INSTANT] => 2011-06-08T19:03:41.443Z [HTTP_SHIB_AUTHNCONTEXT_CLASS] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [HTTP_SHIB_AUTHNCONTEXT_DECL] => [HTTP_SHIB_ASSERTION_COUNT] => [HTTP_NAME] => tommytest [HTTP_PASS] => e06b00d698892623960f9d46efb29533 [HTTP_FNAME] => Tommy [HTTP_LNAME] => Peterson [HTTP_ADDRESS] => 12354 Main Street Suite 330 [HTTP_CITY] => Sterling [HTTP_COUNTRY] => US [HTTP_DESCRIPTION] => [HTTP_WEBPAGE] => [HTTP_WPHONE] => 4085551212 [HTTP_CPHONE] => 4085551212 [HTTP_MAIL] => bl...@something.com[HTTP_LANGUAGE] => [HTTP_UNITID] => [HTTP_TRANSIENTID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [HTTP_PERSISTENTID] => [HTTP_SHIB_APPLICATION_ID] => default [HTTP_REMOTE_USER] => [PATH] => /sbin:/bin:/usr/sbin:/usr/bin [SERVER_SIGNATURE] =>
Apache/2.2.15 (Red Hat) Server at rt-hvcp1-test.hvcp.local Port 80
[SERVER_SOFTWARE] => Apache/2.2.15 (Red Hat) [SERVER_NAME] => rt-hvcp1-test.hvcp.local [SERVER_ADDR] => 172.16.1.84 [SERVER_PORT] => 80 [REMOTE_ADDR] => 172.16.1.15 [DOCUMENT_ROOT] => /var/www/html [SERVER_ADMIN] => root@localhost [SCRIPT_FILENAME] => /var/www/html/drupal/index.php [REMOTE_PORT] => 16710 [AUTH_TYPE] => shibboleth [REDIRECT_QUERY_STRING] => q=findwork [REDIRECT_URL] => /drupal/findwork [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => q=findwork [REQUEST_URI] => /drupal/findwork [SCRIPT_NAME] => /drupal/index.php [PHP_SELF] => /drupal/index.php [REQUEST_TIME] => 1307559960 )


If I use . . .
<LocationMatch "findwork">
AuthType shibboleth
ShibRequireSession On
ShibUseHeaders On
Require shibboleth
</LocationMatch>

Array ( [REDIRECT_OPENSSL_CONF] => ../../conf/openssl.cnf [REDIRECT_SSLEAY_CONF] => ../../conf/openssl.cnf [REDIRECT_Shib-Application-ID] => default [REDIRECT_Shib-Session-ID] => _6921dbc24eb23746ccb4b06b85705741 [REDIRECT_Shib-Identity-Provider] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [REDIRECT_Shib-Authentication-Instant] => 2011-06-08T19:14:24.786Z [REDIRECT_Shib-Authentication-Method] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [REDIRECT_Shib-AuthnContext-Class] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [REDIRECT_Shib-Session-Index] => b69390b5d5087a807247c7732efb62b3fe8437b4090040646259e7d5fc9f1ff1 [REDIRECT_address] => 12354 Main Street Suite 330 [REDIRECT_city] => Sterling [REDIRECT_country] => US [REDIRECT_cphone] => 4085551212 [REDIRECT_fname] => Tommy [REDIRECT_lname] => Peterson [REDIRECT_mail] => bl...@something.com[REDIRECT_name] => tommytest [REDIRECT_pass] => e06b00d698892623960f9d46efb29533 [REDIRECT_transientID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [REDIRECT_wphone] => 4085551212 [REDIRECT_STATUS] => 200 [OPENSSL_CONF] => ../../conf/openssl.cnf [SSLEAY_CONF] => ../../conf/openssl.cnf [HTTP_HOST] => rt-hvcp1-test.hvcp.local [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5 [HTTP_ACCEPT_ENCODING] => gzip, deflate [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7 [HTTP_KEEP_ALIVE] => 115 [HTTP_CONNECTION] => keep-alive [HTTP_COOKIE] => SESS492c5bf24be32ee326896d01b447e0b8=d2bg00lug244k3lsfs0vqmdeu5; has_js=1; _shibsession_64656661756c7468747470733a2f2f72742d68766370312d746573742e687663702e6c6f63616c2f6d6f6f646c65=_6921dbc24eb23746ccb4b06b85705741 [HTTP_SHIB_SESSION_ID] => _6921dbc24eb23746ccb4b06b85705741 [HTTP_SHIB_SESSION_INDEX] => b69390b5d5087a807247c7732efb62b3fe8437b4090040646259e7d5fc9f1ff1 [HTTP_SHIB_IDENTITY_PROVIDER] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth [HTTP_SHIB_AUTHENTICATION_METHOD] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [HTTP_SHIB_AUTHENTICATION_INSTANT] => 2011-06-08T19:14:24.786Z [HTTP_SHIB_AUTHNCONTEXT_CLASS] => urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport [HTTP_SHIB_AUTHNCONTEXT_DECL] => [HTTP_SHIB_ASSERTION_COUNT] => [HTTP_NAME] => tommytest [HTTP_PASS] => e06b00d698892623960f9d46efb29533 [HTTP_FNAME] => Tommy [HTTP_LNAME] => Peterson [HTTP_ADDRESS] => 12354 Main Street Suite 330 [HTTP_CITY] => Sterling [HTTP_COUNTRY] => US [HTTP_DESCRIPTION] => [HTTP_WEBPAGE] => [HTTP_WPHONE] => 4085551212 [HTTP_CPHONE] => 4085551212 [HTTP_MAIL] => bl...@blah.com [HTTP_LANGUAGE] => [HTTP_UNITID] => [HTTP_TRANSIENTID] => https://rt-hvcp1-test.hvcp.local:8443/idp/shibboleth!https://rt-hvcp1-test.hvcp.local/moodle!_2c8ae73555b6c97717fcd8d591c49789 [HTTP_PERSISTENTID] => [HTTP_SHIB_APPLICATION_ID] => default [HTTP_REMOTE_USER] => [PATH] => /sbin:/bin:/usr/sbin:/usr/bin [SERVER_SIGNATURE] =>
Apache/2.2.15 (Red Hat) Server at rt-hvcp1-test.hvcp.local Port 80
[SERVER_SOFTWARE] => Apache/2.2.15 (Red Hat) [SERVER_NAME] => rt-hvcp1-test.hvcp.local [SERVER_ADDR] => 172.16.1.84 [SERVER_PORT] => 80 [REMOTE_ADDR] => 172.16.1.15 [DOCUMENT_ROOT] => /var/www/html [SERVER_ADMIN] => root@localhost [SCRIPT_FILENAME] => /var/www/html/drupal/index.php [REMOTE_PORT] => 17010 [REDIRECT_QUERY_STRING] => q=findwork [REDIRECT_URL] => /drupal/findwork [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => q=findwork [REQUEST_URI] => /drupal/findwork [SCRIPT_NAME] => /drupal/index.php [PHP_SELF] => /drupal/index.php [REQUEST_TIME] => 1307560464 )


click on another link on the site

Array ( [REDIRECT_OPENSSL_CONF] => ../../conf/openssl.cnf [REDIRECT_SSLEAY_CONF] => ../../conf/openssl.cnf [REDIRECT_STATUS] => 200 [OPENSSL_CONF] => ../../conf/openssl.cnf [SSLEAY_CONF] => ../../conf/openssl.cnf [HTTP_HOST] => rt-hvcp1-test.hvcp.local [HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 [HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [HTTP_ACCEPT_LANGUAGE] => en-us,en;q=0.5 [HTTP_ACCEPT_ENCODING] => gzip, deflate [HTTP_ACCEPT_CHARSET] => ISO-8859-1,utf-8;q=0.7,*;q=0.7 [HTTP_KEEP_ALIVE] => 115 [HTTP_CONNECTION] => keep-alive [HTTP_REFERER] => http://rt-hvcp1-test.hvcp.local/drupal/findwork [HTTP_COOKIE] => SESS492c5bf24be32ee326896d01b447e0b8=d2bg00lug244k3lsfs0vqmdeu5; has_js=1; _shibsession_64656661756c7468747470733a2f2f72742d68766370312d746573742e687663702e6c6f63616c2f6d6f6f646c65=_6921dbc24eb23746ccb4b06b85705741 [PATH] => /sbin:/bin:/usr/sbin:/usr/bin [SERVER_SIGNATURE] =>
Apache/2.2.15 (Red Hat) Server at rt-hvcp1-test.hvcp.local Port 80
[SERVER_SOFTWARE] => Apache/2.2.15 (Red Hat) [SERVER_NAME] => rt-hvcp1-test.hvcp.local [SERVER_ADDR] => 172.16.1.84 [SERVER_PORT] => 80 [REMOTE_ADDR] => 172.16.1.15 [DOCUMENT_ROOT] => /var/www/html [SERVER_ADMIN] => root@localhost [SCRIPT_FILENAME] => /var/www/html/drupal/index.php [REMOTE_PORT] => 17015 [REDIRECT_QUERY_STRING] => q=find-learning [REDIRECT_URL] => /drupal/find-learning [GATEWAY_INTERFACE] => CGI/1.1 [SERVER_PROTOCOL] => HTTP/1.1 [REQUEST_METHOD] => GET [QUERY_STRING] => q=find-learning [REQUEST_URI] => /drupal/find-learning [SCRIPT_NAME] => /drupal/index.php [PHP_SELF] => /drupal/index.php [REQUEST_TIME] => 1307560503 )


Also the .htaccess file that sits in /Drupal is shown below:

# Apache/PHP/Drupal settings:
#

SetEnv OPENSSL_CONF "../../conf/openssl.cnf"
SetEnv SSLEAY_CONF "../../conf/openssl.cnf"


# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
Order allow,deny
</FilesMatch>

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Force simple error message for requests for non-existent favicon.ico.
<Files favicon.ico>
# There is no end quote below, for compatibility with Apache 1.3.
ErrorDocument 404 "The requested file favicon.ico was not found.
</Files>

# Set the default handler.
DirectoryIndex index.php

# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.

# PHP 4, Apache 1.
<IfModule mod_php4.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>

# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>


# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
# Enable expirations.
ExpiresActive On

# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600

<FilesMatch \.php$>
# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior. This may
# fail if an error occurs early in the bootstrap process, and it may cause
# problems if a non-Drupal PHP file is installed in a subdirectory.
ExpiresActive Off
</FilesMatch>
</IfModule>

# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on

# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# adapt and uncomment the following:
# RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
# RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment and adapt the following:
# RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
# RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]

# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

#Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

-- Scott


Cantor, Scott E.

unread,
Jun 8, 2011, 4:25:16 PM6/8/11
to shibbole...@internet2.edu
On 6/8/11 3:57 PM, "Tommy Peterson" <Tommy.P...@xpandcorp.com> wrote:
>Now the Shibboleth session header is showing up if I try to access a
>sub-section of the site but I am not logged in.

The only way that would happen that I can think of is if you play games
with the regions of the site that the SP is told to handle (via AuthType
and require) and your app is so complex that it's rewriting requests from
"protected" to "unprotected" URL space.

If the SP processes a request, and attaches the headers or environment
table, and *then* Apache rewrites the request into a subrequest that is
NOT handled by the SP, you create a hole in which the attached information
hangs around from the original request and is probably seen by the
subrequest. The fix for that is to make sure the SP sees the subrequest.
It doesn't have to do anything *but* see it (that's what require
shibboleth is for).

In that situation, I agree that AuthType is probably a good indicator: if
it's not set, the SP didn't handle that particular "final" request, and if
the other data is present, it would be questionable.

Normally the SP never allows that to happen, but you have to know what URL
space is involved. If you have code living at a URL that expects to trust
the information, you have to be sure the SP sees those requests. The
protections the SP uses to prevent client spoofing are in place only when
the requests go through it.

>There is a .htaccess file sitting in /Drupal. I pasted it below that has
>the modrewrite in it. Nothing special.

mod_rewrite is never "nothing special".

-- Scott

Brent Putman

unread,
Jun 8, 2011, 4:30:59 PM6/8/11
to shibbole...@internet2.edu

On 6/8/11 3:57 PM, Tommy Peterson wrote:
> Yes I know that all the pages are hitting index.php. I know that a rewrite of the URL is going on. I think that they are being redirected but I am not for sure.

If you are talking about redirects and how Drupal works, no it does not
do redirects based on the rewriting behavior that we were discussing.
The rewrite is internal, does not produce a redirect, but does affect
what path the modules are actually effectively processing. That's the
whole point of the discussion.


>
>
> If I use <Location /Drupal> (the main site directory) I am fine. All works. I can click around the site and still be logged in. If I use <LocationMatch "findwork"> (which relates to a subsection of the site I am asked to log in to shibboleth, I am authenticated, and the header set (see below). The only difference between the headers for each directive usage is that if I am not using /Drupal I do not get AUTH_TYPE->shibboleth. Also, if I use <LocationMatch "findwork"> and click around the page I lose the session. You can see them below.

I think that's all consistent with what's already been said. If you use
<Location /Drupal>, that's effective for any request (because it covers
/Drupal/index.php). Any other Location directive that doesn't cover
/Drupal/index.php won't be effective for the request, and things in that
block won't be in effect. That explains clearly why the
AUTH_TYPE->shibboleth doesn't show up in the second case you mention.

> All traffic is sent to index.php but the pages are loaded via GET string attached. You can see that in the headings. So if it hits index.php to begin with no matter what page I am trying to hit why won't it just set the session, set AUTH_TYPE=>shibboleth and be done with it,

The AuthType is an Apache directive, not a Shibboleth one. It will be
set when the Location matches the effective request (bearing in mind the
rewriting), and not set when it doesn't. Same is true for literally any
other Apache directive that you put in a Location block.

> as you said yesterday (you said: It's unusual for a request to cause a login redirect but not be processed, and virtually impossible if the rules are expressed with Apache commands.) But you also said "mod_shib processed in general every subrequest, so if the final subrequest moves the request out of the URL space it's told to process then it won't do anything for those requests.")". It hasn't moved. It is still sitting there with index.php.

By "moving" Scott means that what you originally request as
/drupal/foo/bar gets "moved" (rewritten) to
/drupal/index.php?q=foo/bar. If the Location block doesn't cover the
rewritten path, the directives inside it aren't in effect. (Assuming
that everything else that's been said about Location blocks and
mod_rewrite and subrequests is correct. )

> Brent said .... " I don't know what 'drupal_environment_initialize()' does, but clearly what's actually being invoked is /index.php.". I looked up Drupal_environment_initialize() in the API and it just creates the get string. But http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/drupal_environment_initialize/7
>

That was Drupal 7 actually, I was just commenting on the change between
6 and 7. Since you are using Drupal 6, that's not relevant.


> There is a .htaccess file sitting in /Drupal. I pasted it below that has the modrewrite in it. Nothing special.
>

Yes, that's what I already pointed out. You can see the rewrite in there.

Tommy Peterson

unread,
Jun 8, 2011, 6:23:34 PM6/8/11
to shibbole...@internet2.edu
So when you say "The fix for that is to make sure the SP sees the subrequest.

It doesn't have to do anything *but* see it (that's what require
shibboleth is for)." . . . are you saying to account for it in an apache directive somehow? to force authentication? or what exactly do you mean?
________________________________________
From: shibboleth-u...@internet2.edu [shibboleth-u...@internet2.edu] On Behalf Of Cantor, Scott E. [cant...@osu.edu]
Sent: Wednesday, June 08, 2011 4:25 PM

To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] [AUTH_TYPE] => shibboleth

On 6/8/11 3:57 PM, "Tommy Peterson" <Tommy.P...@xpandcorp.com> wrote:

-- Scott


Tommy Peterson

unread,
Jun 8, 2011, 6:25:05 PM6/8/11
to shibbole...@internet2.edu
Yes it is affecting teh path they are processing but if there is no redirect then I don't see how Shibboleth should have an issue with the session. They are all index.php?=. . . . So if one is index.php and it gets protected they all should. So again I fail to see what the error is here but there is one.

So I don't know how to fix this.
________________________________________
From: shibboleth-u...@internet2.edu [shibboleth-u...@internet2.edu] On Behalf Of Brent Putman [put...@georgetown.edu]
Sent: Wednesday, June 08, 2011 4:30 PM


To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] [AUTH_TYPE] => shibboleth

On 6/8/11 3:57 PM, Tommy Peterson wrote:

Brent Putman

unread,
Jun 8, 2011, 7:43:27 PM6/8/11
to shibbole...@internet2.edu
I sort of lost track of what the error is that you are currently
mentioning, but... I did a little test with some rewriting ala Drupal
and the following config and it seems to work (where printenv is just
the stand Apache printenv CGI script):


ScriptAlias /shibtest/printenv /var/www/cgi-shibtest/printenv

<Location /shibtest>
RewriteEngine on


RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico

RewriteRule ^(.*)$ printenv?q=$1 [L,QSA]

AuthType shibboleth
ShibRequestSetting requireSession 0
require shibboleth
</Location>

<Location /shibtest/protected>
ShibRequestSetting requireSession 1
</Location>


So in essence: protect the /drupal root with a lazy session, and then in
Location blocks turn on required session for sub paths that you want to
have a required session. I've used this pattern before, but never with
the rewriting. I'm personally not clear why the Location for the
subpath triggers the Shib session init, since I thought I understood
from Scott that Location blocks were processed against the last internal
subrequest. For a non-existent path like /shibtest/protected/foo/bar,
that is per the above config rewriten as /shibtest/printenv?q=.... But
the above does work, i.e. accessing /shibtest/protected/foo/bar does
result in a required session init.

So to distill down what I think you ought to try:


<Location /drupal>
AuthType shibboleth
ShibRequestSetting requireSession 0
require shibboleth
</Location>

<Location /drupal/cma/history>
ShibRequestSetting requireSession 1
</Location>


or whatever your protected path(s) were. That assumes you are ok with
paths that don't require a session still having the Shib env vars
available if the user has earlier visited a protected area and
establisted a Shib session.

Cantor, Scott E.

unread,
Jun 8, 2011, 7:49:26 PM6/8/11
to shibbole...@internet2.edu
On 6/8/11 7:43 PM, "Brent Putman" <put...@georgetown.edu> wrote:
>I'm personally not clear why the Location for the
>subpath triggers the Shib session init, since I thought I understood
>from Scott that Location blocks were processed against the last internal
>subrequest.

No, what I was saying was that they're both processed. The initial request
for the protected path gets intercepted by mod_shib, and after logging in
and coming back to it, you trigger the rewrite rule which creates the
subrequest that's above it. If that request is not wrapped with the
AuthType/require pair, I think you'd get the behavior in question (no
AuthType but variables from the original protected subrequest).

It's quite possible also that you'd get *headers* but not variables and
simply turning off header support (which doesn't need to be on here) would
also avoid the paradox.

-- Scott

Cantor, Scott E.

unread,
Jun 8, 2011, 7:52:43 PM6/8/11
to shibbole...@internet2.edu
On 6/8/11 6:23 PM, "Tommy Peterson" <Tommy.P...@xpandcorp.com> wrote:

>So when you say "The fix for that is to make sure the SP sees the
>subrequest.
>It doesn't have to do anything *but* see it (that's what require
>shibboleth is for)." . . . are you saying to account for it in an apache
>directive somehow? to force authentication? or what exactly do you mean?

If you want the module to process a request, you need AuthType set to
shibboleth and you need a require rule in effect, even if it's just
"require shibboleth". That does nothing but ensure the module will be
invoked by Apache, without any requirement for a user login or anything
else.

Brent gave you the same solution, as did Peter.

-- Scott

Brent Putman

unread,
Jun 8, 2011, 8:07:11 PM6/8/11
to shibbole...@internet2.edu

On 6/8/11 7:49 PM, Cantor, Scott E. wrote:
> No, what I was saying was that they're both processed. The initial request
> for the protected path gets intercepted by mod_shib, and after logging in
> and coming back to it, you trigger the rewrite rule which creates the
> subrequest that's above it.


Ah, ok. I misunderstood. Then sounds like my solution works as
expected without any mystery.

And the part about both being processed also explains why the Shib data
from my example shows up twice in the printenv output:

eppn="put...@georgetown.edu"
REDIRECT_eppn="put...@georgetown.edu"

Presumably one is coming from the processing of the original request
against the subpath and the other from the rewritten subrequest against
the base script.

I wasn't familar with those REDIRECT_ variables that mod_rewrite
creates. IMHO they are a little misleading since there is in fact no
redirecting going on.


> If that request is not wrapped with the
> AuthType/require pair, I think you'd get the behavior in question (no
> AuthType but variables from the original protected subrequest).
>

Ok, that makes sense, esp if the ones you get are the REDIRECT_ ones
from the pre-rewrite. I don't remember if that's what the OP was getting.


Tommy Peterson

unread,
Jun 8, 2011, 8:12:56 PM6/8/11
to shibbole...@internet2.edu
Yes thank you very much. That worked perfectly as far as I can tell.

I didn't know you could not request the session and it not force the authentication window to pop up.

Thanks again, Brent. I would never have figured out that by the end of this week on my own.

-----Original Message---
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Brent Putman
Sent: Wednesday, June 08, 2011 7:43 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] [AUTH_TYPE] => shibboleth


ScriptAlias /shibtest/printenv /var/www/cgi-shibtest/printenv

This message contains Devin Group confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Cantor, Scott E.

unread,
Jun 8, 2011, 8:13:54 PM6/8/11
to shibbole...@internet2.edu
On 6/8/11 8:07 PM, "Brent Putman" <put...@georgetown.edu> wrote:
>>If that request is not wrapped with the
>> AuthType/require pair, I think you'd get the behavior in question (no
>> AuthType but variables from the original protected subrequest)
>
>Ok, that makes sense, esp if the ones you get are the REDIRECT_ ones
>from the pre-rewrite. I don't remember if that's what the OP was getting.

Even worse, I think some tools might even remap those back to the original
names to hide the switch going on.

As I said, there is no "routine" anything when mod_rewrite is involved.

-- Scott

Tommy Peterson

unread,
Jun 8, 2011, 8:15:18 PM6/8/11
to shibbole...@internet2.edu
Actually, you, Scott, said yesterday " Another thing you can do when requireSession is used is try different require rules such as valid-user or specific rules based on the attributes (as documented) and then you know whether the SP processing layer is in place and allowing access. If that passes along the resources, but the headers don't show up, then you have an issue in the app layer getting the headers, which is not an issue involving the SP."

I just never found the correct match.

Thanks for your help here.

-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Cantor, Scott E.
Sent: Wednesday, June 08, 2011 7:53 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] [AUTH_TYPE] => shibboleth

-- Scott


Reply all
Reply to author
Forward
0 new messages