We're aware of a very few incidents for our Blackboard AS v.8 Learning System in which one or both of two users at different locations "become" the other user -- they see a different person's name wherever Blackboard displays your name, and they see links to the other user's courses. I'm looking for other institutions that have experienced something similar, or anyone who might have a helpful suggestion.
This type of incident was fairly closely correlated to attaching files using the Visual Rich Text Editor, but has happened since we disabled that tool.
This isn't a case of two users behind a shared firewall, or of users in a lab using the same computer.
The modperl log shows a session_id value (the cookie content) being shared with two different user_pk1 values (users). Our single sign-on cookie remains with the user it should stay with. Analysis of browser user agent info from the HTTP headers, as well as correlation of the requested URIs with the Apache logs, show that the user_pk1 value has remained correct.
We run Blackboard in Solaris 10 zones. Our cluster is not like most institutions in that we are using an Apache 2 Web server as our load-balancer and it's not officially supported. (So sigh in relief -- this probably isn't a risk at your institution!) It uses AJP connections to Tomcat and HTTP connections to Blackboard's modperl, bypassing the Apache 1.3 Web server that normally runs in the same zone as the application server. The disableReuse directive is set to off, and we're considering turning it on in order to more closely mimic how Apache 1.3 would likely create new HTTP connections to modperl for each new user.
Our single sign-on has been the focus of attention for Blackboard vendor support. It certainly seems to be the case that one of the parties involved is authenticating during the incident window. We're using the webserver authentication method (bbconfig.auth.type=webserver), with the ExternalAuthModule (auth.type.webserver.impl=blackboard.platform.security.authentication.ExternalAuthModule).
Our SSO is mature (well over 10 years in production across our large University, integrated with many services) and somewhat similar to the CAS authentication module. It works approximately like this: Requests from the client go to Apache 2 and are passed through unchallenged to Blackboard unless the request is in the /login path, by virtue of rewrite rules. If Blackboard does not have a session/does not know the value of REMOTE_USER, Blackboard redirects the user back to the front-end Apache server in the path /login. This causes validation -- Apache redirects to one of the auth servers. If the user is already authenticated, the auth server simply redirects back to Apache. If not, the user is prompted to authenticate. When the auth server has validated, by virtue of the query string that has been passed around, the user sent back to the page he/she requested in Blackboard as a validated session -- this time generating a valid Blackboard session and resulting in the page the user wanted being returned. All future clicks until the Blackboard session is invalidated do not cause the Apache server to validate...unless of course they're in the /login path. These clicks just pass through unchallenged.
I'd appreciate any feedback you want to send me.