Shibboleth Developers

[Nate Klingenstein <>]

*Shibboleth-Dev Conference Call*
January 5, 2004

*Participants*

Steven Carmody -- Brown (chair)
Derek Atkins -- MIT
Scott Cantor -- OSU
Walter Hoehn -- Columbia
Bob Morgan -- Washington
Barry Ribbeck -- UTHSC-H
John-Paul Robinson -- UAB
Renee Shuey -- Penn State
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

	Scott found a significant memory leak in the C target code, and has 
checked patches for this and some other issues into CVS.  Penn State 
and Buffalo will be downloading and testing the fixes.
	The Shibboleth project may move from its current approach of releasing 
large versions to instead releasing more incremental changes as the 
code base matures and stabilizes.

HS Signing Performance

	There have been lingering issues about the amount of load generated by 
the HS implemented in Java.  Penn State, which recently used Shibboleth 
as the I&A process in a wide-spread deployment of institutional music 
sharing using Napster, addressed this by standing up six powerful 
origin servers, but it's important to address the performance issues 
more generally for smaller deployments.
	Walter has been fiddling with using OpenSSL for HS signing, 
implemented as a sort of wrapper around the Java-based handle service.  
A simple MD5 and SHA-1 hash was a test, where he performed only one 
iteration of hashing, where it proved much slower to use OpenSSL than 
Java's crypto libs.  However, when he tested through many iterations, 
he realized it's only slow the first time going through JNI; Scott 
suspected this was due to the need to load the library, but Walter was 
still surprised at how slow it was.  Part of the reason why OpenSSL is 
generally as fast as it is is that vendors tend to ship one that is 
very well-supported by the hardware.
	There's a set of libraries that Scott has tested that utilize a 
Rainbow card, which led to an improvement by a factor of 2 or 3 in his 
tests.  This is not as much an increase as may be expected, which Scott 
suspects is because the Rainbow card isn't thread-safe.  The hardware 
access is serialized, and it only scales on multi-process architectures 
such as Apache's.  Given that Java is threaded, Scott speculated that 
that was a bottleneck for performance.
	Another option would be to code the entire HS all over again in C, if 
it's decided that there's no way to make the Java perform well enough.  
Scott will decide what should be done after more noodling through the 
summer, given there are no exceedingly pressing deployments that would 
require better performance.
	Scott's also worried about the performance of the JVM's threading 
mechanisms, but doesn't think there's much that can be done about it 
there because most deployments of the HS have to be behind Apache.  In 
that architecture, Tomcat isn't built in a way that the number of 
active threads can be restricted without limiting the traffic from 
Apache, which may not be suitable for some deployments.  The best 
choice then becomes to implement a throttle within the HS, which would 
be recommended for most deployments but not mandatory.  This will be 
eventually documented in a tuning guide.

Re-Direct Timestamps

	Scott wants to enable people to use the back button of their browsers 
in the most intuitive way possible while using Shibboleth.  Right now, 
if the user tries to go back past a page accessed using Shibboleth to 
before that session, the browser goes back to the POST transmission of 
the SAML attribute assertion, causing a re-post and the browser to be 
kicked back into the webspace the user was trying to exit.  If the user 
were to get past this and their local WebISO page, they might have the 
same problem if the WAYF had cached a session for them.
	He suggested a basic solution of appending timestamps to each of the 
GET URL's for these steps in the flows, and received significant 
pushback.  This would consist of a simple timestamp that the login 
service would compare to a fixed thresh-hold, which could be made 
tight, on the order of five minutes.  This would be enough time to 
accommodate the redirect in any situation.  Upon receiving a request 
which were past the thresh-hold, the HS or WAYF could desplay some kind 
of expiration page which would have Javascript stepping the browser 
back one more page, out of the Shibboleth session entirely.
	Walter pushed back on this, saying that it could lead to inconsistent 
behavior and be worse for the users than before: if back were pressed 
before the timestamp ran out, it wouldn't work, but if it were pressed 
after that, it would.  Also, if the user's intent were to log into the 
application again when they press back, it would be difficult.
	Renee hasn't heard any sort of feedback on whether this is a problem 
from the help desk at Penn State, which implies that it may not be one. 
 Additionally, similar systems, such as a campus WebISO, would be 
expected to have the same problem.  Pubcookie doesn't have this issue, 
and doesn't use timestamps, but Bob was unsure how it worked. [AI] Bob 
will check to see how Pubcookie avoids this issue.
	This problem will be resolved anyway in SAML 2.0, which will almost 
certainly contain fields that can be used to handle this.  Steven will 
put this on next week's agenda to reach closure on an approach.

*Action Items*

1.  Bob will check to see how Pubcookie handles the use of the back 
button and its potential to cause replays.