Shib with REST and AJAX Best Practices
Russell J Yount
We have some developers here using REST and AJAX together with Shibboleth. The problem of the Javascript not understanding the 302 redirects that shibboleth uses when re-authenticating has come up.
The groups solution has been to:
1) Change the sessions statement to look something like this:
<Sessions lifetime="28800" timeout="86400" checkAddress="false" relayState="ss:mem" handlerSSL="true">
The key here is setting the lifetime value lower than the timeout value.
2) Add the following directives to the httpd.conf file (they added them globally, but there is no reason it couldn't be done at a directory level I suppose):
Header unset ETag
Header set Cache-Control "max-age=0, must-revalidate"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
This seems to work for them. Is there a better way to handle this?
One possible alternative I have suggested would be to have the application manage its own session (using on authentication page protected by Shibboleth).
What is the best practice for this?
-Russ
Russell J. Yount r...@cmu.edu
Identity Services, Carnegie Mellon University
Peter Schober
> We have some developers here using REST and AJAX together with
> Shibboleth. The problem of the Javascript not understanding the 302
> redirects that shibboleth uses when re-authenticating has come up.
Not sure what setup/scernario exactly you have in mind but for REST as
in "non-browser access to shib proteced resources" the usual answer is
to not use the SAML profile explicitly designed for web browser
access, but use ECP instead.
> <Sessions lifetime="28800" timeout="86400" checkAddress="false" relayState="ss:mem" handlerSSL="true">
>
> The key here is setting the lifetime value lower than the timeout
> value.
Sounds a bit like Voodoo. Lifetime specifies is an upper limit for the
session to be valid, timeout an inactivity limit between requests for
the session to remain active. If the upper limit is lower than the
inactivity limit you're simple not making use of the latter (and might
as well disable the check with timeout="0", like the documentation
says).
-peter
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Peter Schober
> application manage its own session (using on authentication page
> protected by Shibboleth).
Leaving session management for your protected resource to the
application (instead of the webserver by means of mod_shib) does not
avoid the app having to authenticate /somewhere/ once correctly.
It just means you'll have two sessions to take care of, one of which
can be forgotten about (low timeout value) after a minute or two.
Russell J Yount
> Not sure what setup/scernario exactly you have in mind but for REST as in "non-browser access to shib proteced resources" the usual answer is to not use the SAML profile explicitly designed for web browser access, but use ECP instead.
In our cast the Javascript running in a user's browser is communicating with an Ruby on Apache web server.
* Peter Schober <peter....@univie.ac.at>, Tuesday, September 13, 2011 9:05 AM
> Sounds a bit like Voodoo. Lifetime specifies is an upper limit for the session to be valid, timeout an inactivity limit between requests for the session to remain active. If the upper limit is lower than the inactivity limit you're simple not making use of the latter (and might
as well disable the check with timeout="0", like the documentation says).
We tried timeout="0", but that broke shibboleth authentication.
Peter Schober <peter....@univie.ac.at>, Tuesday, September 13, 2011 9:11 AM
>Leaving session management for your protected resource to the application (instead of the webserver by means of mod_shib) does not avoid the app having to authenticate /somewhere/ once correctly. It just means you'll have two sessions to take care of, one of which can be forgotten about (low timeout value) after a minute or two.
The thinking was the application could have better control or when re-authentication happen.
-Russ
Cantor, Scott
>The groups solution has been to:
>
>1) Change the sessions statement to look something like this:
>
><Sessions lifetime="28800" timeout="86400" checkAddress="false"
>relayState="ss:mem" handlerSSL="true">
>
>The key here is setting the lifetime value lower than the timeout value.
The session will still expire eventually, so I don't understand the value
of that.
>2) Add the following directives to the httpd.conf file (they added them
>globally, but there is no reason it couldn't be done at a directory level
>I suppose):
I don't understand what that has to do with AJAX either. Anything the
browser is accessing obviously needs appropriate cache policy. If it's
dynamic content, then obviously it should be marked as such.
>
>This seems to work for them. Is there a better way to handle this?
I don't think either has anything to do with the problem.
>
>One possible alternative I have suggested would be to have the
>application manage its own session (using on authentication page
>protected by Shibboleth).
If you want the application to manage the session, you can just use lazy
sessions with the SP also. Same effect.
>
>What is the best practice for this?
Fix HTTP? There's no way to use AJAX in conjunction with security
mechanisms that the client doesn't know anything about. At the end of the
day, it's a broken model.
-- Scott
Cantor, Scott
>
>We tried timeout="0", but that broke shibboleth authentication.
Did you file a bug?
-- Scott
Russell J Yount
I just submitted the bug.
-Russ
-----Original Message-----
From: users-...@shibboleth.net [mailto:users-...@shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, September 13, 2011 9:57 AM
To: us...@shibboleth.net
Subject: Re: Shib with REST and AJAX Best Practices
On 9/13/11 9:29 AM, "Russell J Yount" <r...@cmu.edu> wrote:
>
>We tried timeout="0", but that broke shibboleth authentication.
Did you file a bug?
-- Scott
--
Russell J Yount
>>globally, but there is no reason it couldn't be done at a directory
>>level I suppose):
>I don't understand what that has to do with AJAX either. Anything the browser is accessing obviously needs appropriate cache policy. If it's dynamic content, then obviously it should be marked as such.
Scott, Let me explain.
The browser references an html page which contains javascript modules and a command to start a javascript operation to paint users browser screen.
The first time the html page is referenced, shibboleth intercepts the GET of the html page and authenticates, then javascript modules are download and started.
Assuming some time passes, maybe users does some things and shibboleth authentication expires.
Case 1: In next reference to the html page the user is going to page and the browser does not do a GET of the html page because it is cached, the javascript modules however are always downloaded and Shibboleth intercepts the download and sends a 302 which the javascript does not understand.
Case 2: A user is at the html page, javascript has already painted screen, user clicks sending an event to javascript which send a REST request to Apache/Ruby, Shibboleth intercepts the REST request and sends a 302 which the javascript does not understand.
If the html page is set to not cache in both cases references to the html page cause browser to do a GET and shibboleth authentication occurs before the javascript download in case 1, or REST request is sent in case 2.
-Russ
-----Original Message-----
From: users-...@shibboleth.net [mailto:users-...@shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, September 13, 2011 9:56 AM
To: us...@shibboleth.net
Subject: Re: Shib with REST and AJAX Best Practices
On 9/13/11 8:16 AM, "Russell J Yount" <r...@cmu.edu> wrote:
>The groups solution has been to:
>
>1) Change the sessions statement to look something like this:
>
><Sessions lifetime="28800" timeout="86400" checkAddress="false"
>relayState="ss:mem" handlerSSL="true">
>
>The key here is setting the lifetime value lower than the timeout value.
The session will still expire eventually, so I don't understand the value
of that.
>2) Add the following directives to the httpd.conf file (they added them
>globally, but there is no reason it couldn't be done at a directory level
>I suppose):
I don't understand what that has to do with AJAX either. Anything the
browser is accessing obviously needs appropriate cache policy. If it's
dynamic content, then obviously it should be marked as such.
>
>This seems to work for them. Is there a better way to handle this?
I don't think either has anything to do with the problem.
>
>One possible alternative I have suggested would be to have the
>application manage its own session (using on authentication page
>protected by Shibboleth).
If you want the application to manage the session, you can just use lazy
sessions with the SP also. Same effect.
>
>What is the best practice for this?
Fix HTTP? There's no way to use AJAX in conjunction with security
mechanisms that the client doesn't know anything about. At the end of the
day, it's a broken model.
-- Scott
Cantor, Scott
>
>If the html page is set to not cache in both cases references to the html
>page cause browser to do a GET and shibboleth authentication occurs
>before the javascript download in case 1, or REST request is sent in case
>2.
I can't think why the browser would refetch the HTML page in the second
case. It's already loaded and the event on the page should just run the
script that's already in the client. So I would be somewhat in doubt that
it would behave that way on all browsers.
Jim Fox
>
> One possible alternative I have suggested would be to have the application manage its own session (using on authentication page protected by
> Shibboleth).
>
We handle this situation by having the application manage its
own sessions. If an expired session is encountered on a normal
browser request the user is redirected via shib to reauthenticate.
If an expired session cookie is encountered during an ajax request we
send an error response with content that indicates reauthentication
is needed. On those errors a popup informs the user of a need to
refresh the page to reauthenticate.
Jim