[Shib-Users] Redirect question
Tommy Peterson
I have the following <Location> directive and all works a-ok. I get the shibboleth page. I log in. I’m authenticated. I am redirected to the actual page. The shibboleth header/variables info of course appears.
<Location /drupal>
AuthType shibboleth
ShibRequireSession On
ShibUseHeaders On
require shibboleth
</Location>
But, if I go any deeper than that main/top directory I have issues. I get the Shibboleth log in page. I authenticate (per the logs) . The process is returned to the SP (per the logs). And I am returned to the page I requested but there is no shibboleth header info—no environment variables.
<Location /drupal/cma/history>
AuthType shibboleth
ShibRequireSession On
ShibUseHeaders On
require shibboleth
</Location>
Any suggestions on where to look for the source of the issue? There are no errors in the logs, not the IDP, SP, or apache logs. Obviously the apache directives are working or I would not be getting the shibboleth log in page. So I am lost.
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.
Kevin P. Foote
Generally when your protecting your (an) application you protect the login page or
routines that handle the extraction of attributes out of the header /
env variables to create a valid session with your application.
An example is protecting Movable-type .. we protect the main cgi that
gets called when a user wants to login. The operations inside the CGI
handle the extraction of all the attributes into useful stuff for
Movable-type
You can always view what the SP has been sent from here
/Shibboleth.sso/Session
------
thanks
kevin.foote
On Mon, 6 Jun 2011, Tommy Peterson wrote:
-> I have the following <Location> directive and all works a-ok. I get the shibboleth page. I log in. I'm authenticated. I am redirected to the actual page. The shibboleth header/variables info of course appears.
->
-> <Location /drupal>
-> AuthType shibboleth
-> ShibRequireSession On
-> ShibUseHeaders On
-> require shibboleth
-> </Location>
->
-> But, if I go any deeper than that main/top directory I have issues. I get the Shibboleth log in page. I authenticate (per the logs) . The process is returned to the SP (per the logs). And I am returned to the page I requested but there is no shibboleth header info-no environment variables.
->
-> <Location /drupal/cma/history>
-> AuthType shibboleth
-> ShibRequireSession On
-> ShibUseHeaders On
-> require shibboleth
-> </Location>
->
-> Any suggestions on where to look for the source of the issue? There are no errors in the logs, not the IDP, SP, or apache logs. Obviously the apache directives are working or I would not be getting the shibboleth log in page. So I am lost.
->
-> 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.
>Any suggestions on where to look for the source of the issue?
For a given request, there are a handful of fixed headers or environment
variables that are set for any request that is associated with a session
and processed by the SP.
Shib-Identity-Provider and a few others documented.
If they're not set, the SP didn't see the request or the session's just
not there. 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.
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.
You also, in the case of different require rules, can get more detailed
logging in Apache when its level is turned up.
-- Scott
Tommy Peterson
Tommy Peterson
I had two tabs open just now after getting Kevin's response. One was for the login and one was for Shibboloeth.sso/Session. I refreshed the session page after logging in and still see :
Attributes
address: 1 value(s)
city: 1 value(s)
country: 1 value(s)
cphone: 1 value(s)
fname: 1 value(s)
lname: 1 value(s)
mail: 1 value(s)
name: 1 value(s)
pass: 1 value(s)
transientID: 1 value(s)
wphone: 1 value(s)
all of which are my attributes.
So I'm guessing this is the application--like caching or something. I will look there as this is not a Shibboleth issue really.
Thanks.
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Cantor, Scott E.
Sent: Monday, June 06, 2011 2:01 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] Redirect question
-- Scott
Brent Putman
One possible issue might be how Drupal uses mod_rewrite. From your
example, accesssing "/drupal/cma/history", you probably already know
that that's called a "clean URL" and what is really happening under the
covers is that Drupal (via Apache directives) is using mod_rewrite to
cause that to actually be processed by httpd as
"/drupal/index.php?q=cma/history".
So depending on the order in which mod_shib and mod_rewrite do their
respective things internally within httpd, perhaps there is an issue.
Or not. I just bring it up as a potential issue. Scott?
Cantor, Scott E.
>So depending on the order in which mod_shib and mod_rewrite do their
>respective things internally within httpd, perhaps there is an issue.
>Or not. I just bring it up as a potential issue. Scott?
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.
-- Scott
Brent Putman
On 6/6/11 2:51 PM, Cantor, Scott E. wrote:
>
> 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.
Ok. I'm not 100% sure then regarding what the final subrequest is, but
it sounds like that might in fact be a problem. What's actually seen
and processed by PHP and Drupal does ultimately become
/index.php?q=path-to-node.
I should have also added that that exact mechanism corresponds to Drupal
6.x. In just looking at the dist for Drupal 7.x (which I have never
personally run), it seems it is a little different, but ultimately httpd
is still invoking index.php.
Drupal 6.x:
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
Drupal 7.x:
# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteRule ^ index.php [L]
I don't know what 'drupal_environment_initialize()' does, but clearly
what's actually being invoked is /index.php.
Tommy Peterson
But I turned on LiveHTTPHeaders and nothing seems to be redirecting out of the ordinary. Unless that tool doesn't capture it.
And I was th inking this was the problem yesterday and turned off clean URLs to see what it would do. Still same problem.
The weird thing is that http://rt-hvcp1-test.hvcp.local/drupal works. That is not its path. It is also rewritten behind the scenes/redirected.
And I am using Drupal 6.x.
So I don't know. I am going to have to dig in the code of the module I guess. This just makes no sense. But this is off Shibboleth topic I guess. Sorry.
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Brent Putman
Sent: Monday, June 06, 2011 3:06 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] Redirect question
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.
Peter Schober
> I have the following <Location> directive and all works a-ok. I get the shibboleth page. I log in. I'm authenticated. I am redirected to the actual page. The shibboleth header/variables info of course appears.
>
> <Location /drupal>
> AuthType shibboleth
> ShibRequireSession On
> ShibUseHeaders On
> require shibboleth
> </Location>
>
>
> <Location /drupal/cma/history>
> AuthType shibboleth
> ShibRequireSession On
> ShibUseHeaders On
> require shibboleth
> </Location>
Since you're not enforcing a session here (as the Drupal Shib module
uses Lazy Sessions) why should the latter config snippet be
preferrable to the former? Any actual authentication needs to be
handled/initialized by the application (Drupal) anyway.
So which pages/resources need protection etc. is up to your
application. So I would use <Location /drupal-base-url> either way.
Other than that why use "ShibUseHeaders On"? Drupal certainly doesn't
need this (judging from the successful use of Drupal on our webhosting
environment).
-peter
Cantor, Scott E.
>But I turned on LiveHTTPHeaders and nothing seems to be redirecting out
>of the ordinary. Unless that tool doesn't capture it.
Well, no, there's no way it could. Those are headers from the client and
response headers from the server. Using headers with the SP on Apache is
not advised, not necessary with Drupal (according to Peter) and not either
of those categories in any case.
>The weird thing is that http://rt-hvcp1-test.hvcp.local/drupal works.
>That is not its path. It is also rewritten behind the scenes/redirected.
If you have a Location of /drupal covered, anything it rewrites to in that
space will work.
-- Scott
Tommy Peterson
The problem appears to be the final redirect that Drupal does. . . for whatever reason. But as has been confirmed I still don't see how/why /Drupal works but /Drupal/cma/history doesn't.
And we cannot have the user logging in before hitting the page. A loto f this content is open to the world.
Thanks.
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Peter Schober
Sent: Monday, June 06, 2011 3:27 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] Redirect question
Brent Putman
On 6/6/11 3:10 PM, Tommy Peterson wrote:
> Thanks.
>
> But I turned on LiveHTTPHeaders and nothing seems to be redirecting out of the ordinary. Unless that tool doesn't capture it.
Scott more or less already said this,but: redirect != rewrite. You will
not see the rewrite of the URL in LiveHeaders, b/c it's happening
entirely internally within httpd.
>
> And I was th inking this was the problem yesterday and turned off clean URLs to see what it would do. Still same problem.
I don't think that would affect anything.
In case it wasn't clear, the hypothesis is that protecting /drupal
works, b/c httpd is ultimately invoking /drupal/index.php and that's in
mod_shib's protected path. And protecting /drupal/cma/history doesn't
work for exactly the same reason - mod_shib sees that you are ultimately
processing /drupal/index.php and that's not in the protected space
(/drupal/cma/history) so it's treated as not protected and the Shib info
isn't exposed.
So even if you turn off clean URL's, and have the browsers explicitly
hitting content as /drupal/index.php?q=path/to/node, paths below /drupal
aren't going to work - because the user isn't actually calling that
path. It doesn't introspect the query string, etc.
I'm not sure exactly how the Drupal Shib authN module(s) work, but they
must do something to get around this issue.
Tommy Peterson
--Tommy
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Brent Putman
Sent: Monday, June 06, 2011 4:58 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] Redirect question
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.
Christopher Bongaarts
> In case it wasn't clear, the hypothesis is that protecting /drupal
> works, b/c httpd is ultimately invoking /drupal/index.php and that's in
> mod_shib's protected path. And protecting /drupal/cma/history doesn't
> work for exactly the same reason - mod_shib sees that you are ultimately
> processing /drupal/index.php and that's not in the protected space
> (/drupal/cma/history) so it's treated as not protected and the Shib info
> isn't exposed.
>
> So even if you turn off clean URL's, and have the browsers explicitly
> hitting content as /drupal/index.php?q=path/to/node, paths below /drupal
> aren't going to work - because the user isn't actually calling that
> path. It doesn't introspect the query string, etc.
Can Apache's LocationMatch regexes hit query strings?
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
Brent Putman
On 6/6/11 4:35 PM, Tommy Peterson wrote:
> But I want to enforce the session and I want to force the user to use the Shibboleth log in (if they have not authenticated yet) to access Drupal content. I want this because there is another application--Moodle--embedded in Drupal that picks up the Shibboleth authentication to create a SSO--the requirement. The Moodle part works. And the Drupal part works. I don't want lazy sessions which is why I used the ShibrequireSession On. I am aware that Drupal has its own authentication mechanism but that alone won't create SSO.
>
> The problem appears to be the final redirect that Drupal does. . . for whatever reason. But as has been confirmed I still don't see how/why /Drupal works but /Drupal/cma/history doesn't.
>
> And we cannot have the user logging in before hitting the page. A loto f this content is open to the world.
>
(With the caveat of not having tried any of this): I think what you'd
have to do is something like this:
1) protect /drupal with a lazy session
2) do something in Drupal and/or the content that causes the desired
path(s) to require authN and therefore redirect to the Shib session
initiator when there is no Shib session
#1 is necessary because of the way the rewrites happen, as we've been
discussing
#2 is then how you get the required-ness of Shib authN for certain paths
only. You have to do in the app rather than in Shib. In taking a quick
look at the Shib Drupal module, I don't immediately see that it supports
something like that (configuring a list of "protected" paths). It's
probably not too hard implement, there are other modules like Secure
Pages that do something similar (in that case, requiring SSL for certain
paths and redirecting appropriately). Off-hand that would seem to me
the appropriate feature request to make to the Drupal module person.
Brent Putman
On 6/6/11 5:17 PM, Christopher Bongaarts wrote:
>
> Can Apache's LocationMatch regexes hit query strings?
>
No, I don't think so. the docs say:
> For all origin (non-proxy) requests, the URL to be matched is a URL-path of the form /path/. No scheme, hostname, port, or query string may be included.
Not sure that it would help much anyway. It would only work if you
permanently turned off clean URL's (which most people want on for a
reason) or if the LocationMatch can be made to work against the
rewritten request rather than the original request from the client.
Cantor, Scott E.
>
>On 6/6/11 5:17 PM, Christopher Bongaarts wrote:
>
>>
>> Can Apache's LocationMatch regexes hit query strings?
>>
>
>No, I don't think so. the docs say:
The SP can, but is very fragile in doing so.
>>Not sure that it would help much anyway. It would only work if you
>permanently turned off clean URL's (which most people want on for a
>reason) or if the LocationMatch can be made to work against the
>rewritten request rather than the original request from the client.
Location settings do apply to the rewritten subrequest.
-- Scott
Tommy Peterson
Tommy
-----Original Message-----
From: shibboleth-u...@internet2.edu [mailto:shibboleth-u...@internet2.edu] On Behalf Of Cantor, Scott E.
Sent: Monday, June 06, 2011 5:34 PM
To: shibbole...@internet2.edu
Subject: Re: [Shib-Users] Redirect question
-- Scott
Brent Putman
On 6/6/11 5:33 PM, Cantor, Scott E. wrote:
>
>
> Location settings do apply to the rewritten subrequest.
>
Ok, good to know. But since it can't match on the query string, I don't
think it buys you anything.
Cantor, Scott E.
>
>On 6/6/11 5:33 PM, Cantor, Scott E. wrote:
>>
>>
>> Location settings do apply to the rewritten subrequest
>
>think it buys you anything.
Probably not. The fact that they don't allow that is one reason I knew it
was a dead end in the SP. There are so many ways to spoof a query string
check that it just isn't helpful unless the goal is to apply some kind of
usability related setting and not a security one.
-- Scott
Brent Putman
On 6/6/11 5:20 PM, Brent Putman wrote:
> #2 is then how you get the required-ness of Shib authN for certain paths
> only. You have to do in the app rather than in Shib. In taking a quick
> look at the Shib Drupal module, I don't immediately see that it supports
> something like that (configuring a list of "protected" paths). It's
> probably not too hard implement, there are other modules like Secure
> Pages that do something similar (in that case, requiring SSL for certain
> paths and redirecting appropriately). Off-hand that would seem to me
> the appropriate feature request to make to the Drupal module person.
If there are any Drupal modules which let you specify certain paths to
have arbitrary PHP code invoked before the content, then this could be
done, I think. Or if you can embed PHP in the content. I know this
can be done, but not sure if relevant to your use case.
You might be able to simulate this also with one of the httpd modules
that let's you essentially script httpd, like mod_perl. But now we're
getting way out there....
Peter Schober
> > <Location /drupal/cma/history>
> > AuthType shibboleth
> > ShibRequireSession On
> > ShibUseHeaders On
> > require shibboleth
> > </Location>
>
> Since you're not enforcing a session here (as the Drupal Shib module
> uses Lazy Sessions) why should the latter config snippet be
> preferrable to the former?
* Tommy Peterson <Tommy.P...@xpandcorp.com> [2011-06-06 22:35]:
> But I want to enforce the session and I want to force the user to
> use the Shibboleth log in (if they have not authenticated yet) to
> access Drupal content. I want this because there is another
> application--Moodle--embedded in Drupal that picks up the Shibboleth
> authentication to create a SSO--the requirement. The Moodle part
> works. And the Drupal part works. I don't want lazy sessions which
> is why I used the ShibrequireSession On. I am aware that Drupal has
> its own authentication mechanism but that alone won't create SSO.
Ah, I was mislead by the "require shibboleth" directive, which IMHO
only ever makes sense if you don't actually require anything but need
to syntactically (httpd requires an AuthType and a require directive
for a mod_auth[nz]_* module to kick in here). I somehow ignored the
"ShibRequireSession On" because of that.
So that should probably be "require valid-user" then, if you really
don't care about authorization (so that authn == authz).
Given the other part of this thread (URL rewriting) I doubt this will
change anything, though.
-peter