There has been usage of SecurityAssociation directly in the client code by users as well as JEMS projects. We really need to be getting a Client SPI from the security project.

The SPI should include things like passage of username/password, callback handler, jaas config name (if the SPI implementation has to do JAAS).

The SPI implementation can make use of SASL on which GSS can be placed. GSS works on the concept of tokens and can use encryption.

One concept that I have not checked out is whether SASL needs both SASL client as well as SASL server because SASL is primarily used for a challenge/response type scenario. I want to be just doing SASL client.

I did some more reading on SASL. As I mentioned earlier, it is a challenge/response based mechanism between the client and the server. So there will be multiple message flow between the client and server.

In the case of EJB invocations, there is a notion of clients and servers. In the case of web invocations, there is just server that we are dealing with.

Scott, do you think we should make an attempt at SASL? The details will be hidden behind the Security Client implementation and server side security manager implementation.