2 Replies Latest reply on May 2, 2007 11:50 AM by Anil Saldanha

    Security Client SPI

    Anil Saldanha Master

      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.

      A rough outline of the security client spi is:

      public interface SecurityClient
       public void setUserName(String username)
       public void setPrincipal(Principal p)
       public void setCredential(Object cred)
       public void setJaasConfigName(String str)
       //Advanced stuff for GSS
       public setEncryption(String algo)

      I will work out the SPI in the next few days.

        • 1. Re: Security Client SPI
          Anil Saldanha Master

          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.

          Any feedback?

          • 2. Re: Security Client SPI
            Anil Saldanha Master

            I have checked in the SPI for the client. Here is a test case in AS5 that tests the security client for simple/jaas. SASL implementation will be done in securirty 2.0.1 or later.


            Here is the SPI for you:

            public abstract class SecurityClient
             public void login() throws LoginException
             public void logout()
             public void setSimple(Object username, Object credential)
             public void setJAAS(String configName, CallbackHandler cbh)
             public void setSASL(String mechanism, String authorizationId,
             CallbackHandler cbh)

            How does one get hold of the security client? Here are possible ways:
            //Get the default
            SecurityClient sc = null;
             sc = SecurityClientFactory.getSecurityClient();
             assertNotNull("SecurityClient != null",sc);
            //Pass in a FQN
             sc = SecurityClientFactory.getSecurityClient("org.jboss.security.client.JBossSecurityClient");
             assertNotNull("SecurityClient != null",sc);
            //Pass in a Class object whose instances are needed (Not big fan of this method)
            sc = SecurityClientFactory.getSecurityClient(JBossSecurityClient.class);
             assertNotNull("SecurityClient != null",sc);

            Hopefully now your integration tests do not have to do SecurityAssociation.setPrincipal and SecurityAssociation.setCredential