Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add comment on CAS

...

JSecurity or more usefully http://www.jsecurity.org/ is a well established security framework that is now moving to apache and is currently under incubation. It's ASL 2.0. It is not yet integrated in Geronimo and does not appear to directly relate to javaee spec security yet although it may be useful to integrate as a JACC provider. Some details on SSO support are at http://www.jsecurity.org/node/996 which appear to indicate that it relies on a cross-context psuedo session and would need a custom communication with a particular server to share session contents.

CAS (Central Authentication Server)

CAS is a BSD licensed framework that is kerberos like. A user signs onto the central server, which maintains a cookie and session remembering the login. Applications redirect to the central server for authentication and the central server redirects back after authentication, including a ticket. The client app then validates the ticket against the central server. Apparently the only information returned is "validated" and the user id; there is no role information returned. Thus, as with openid, each application will need to maintain identity to role mapping. There is a spring security integration but I can find no direct jetty or tomcat integrations that allow use of the javaee security constraints.

JOSSO

JOSSO is GPL licensed which makes its use with ASL licensed code difficult to understand for me. It appears to have a geronimo-tomcat integration. Use with jetty or geronimo-jetty would require modifying the jetty server to include an interceptor or handler before the security handler so the sso information could be injected before the normal security handling. Presumably this code would be GPL thus making the use of Jetty or Geronimo GPL. For this reason Geronimo can't include integration code for JOSSO.
JOSSO works by having a central authentication server ("gateway") and "sessions" that are shared between the auth server and secured "partner" apps. Presumably the session id is shared using a cookie. There is some combination of an authentication message flow that redirects to the central auth server and a JAAS login module for the partner app that retrieves the auth info from the central server using SOAP. It's possible that the authentication message flow, currently implemented apparently via a tomcat valve, could be implemented using JASPI, thus making it more cross-platform. There's some description here:
http://www.josso.org/confluence/display/JOSSO1/Architecture+Overview

...