...
A CASify Lombardi - Teamworks Application via Jaas exists for JBoss. It has the additional function of obtaining a Proxy Granting Ticket so the Subject and Principal objects in the JBoss security context can "serialize" and propagate to a second JBoss system when there is a remote EJB call. However, in the current state of CAS protocol, use of Proxy tickets requires a callback to a configured HTTPS port, and that cannot be done without some container-specific configuration and logicThe first JBoss authenticates the ticket as described previously, but it obtains a Proxy Granting Ticket and stores it in the Subject/Principal structure. Then when the JBoss Security Context asks the Subject to serialize itself (which only happens when you are making a remote EJB call), it obtains a Proxy Service Ticket for the remote system and sends its ID as content of the serialized Subject/Principal. On the receiving system, when these objects are de-serialized the code validates the Proxy Service Ticket and inserts the Netid in the secondary Subject/Principal.
There are a number of problems that make this code difficult to generalize. For one thing, the Proxy Callback requires that code be inserted into the Servlet layer of the container, and then the Ticket Validation and the Callback routine have to synchronize what they are doing. This is probably a system dependent solution. More importantly, you can only get a Proxy ticket if you know the service= of the receiving system, and that implies understanding the current system specific Security context and request processing context.Again, it will be interesting to see how SPNEGO handles this same problem if it gets integrated into JBoss, but that would not solve the problem for another container. Strictly speaking, the uncertainties here are not in the JAAS function but rather some missing features of the javax.security.auth.Subject interface.