6 Replies Latest reply on Oct 30, 2006 5:54 AM by mageshbk

    ws-security JBWS-638 - Design Notes

    mageshbk

      SecurityStore
      ==========
      Will no longer hold the keystore and truststore, rather will hold a reference to a JaasSecurityDomain Object. This will be used to lookup the security configuration and also to encode/decode.

      Since we want to make this keystore configuration available from jboss-wsse-server.xml also, we allow the user to

      Either specify the jaasSecurityDomain in wsse-server.xml

      Or

      Allow him to set the complete keystore properties as before. But this time the properties will be created as a JassSecurityDomain and stored as Object

      This way both the approach will use the same mechanism to use jaasSecurityDomain to cater to the security needs.


      What needs to be done:
      ==================

      1. jboss-wsse-server.xml needs to be adjusted to provide a facility for a jaasSecurityDomain.
      2. org.jboss.ws.wsse.SecurityStore will need to match the above logic to lookup JNDI and do the needful.
      3. org.jboss.ws.wsse.WSSecurityDispatcher will create the SecurityStore differently using the jassSecurityDomain name or the keystore properties depending on the configuration.
      4. org.jboss.ws.metadata.wsse.WSSecurityConfiguration needs to be changed to add the new jassSecurityDomain property.

      The only problem that I have is where and who will initialize the kestore configurations from jboss-wsse-server.xml as a jassSecurityDomain MBean? Will it be in SecurityStore?

        • 1. Re: ws-security JBWS-638 - Design Notes
          jason.greene

          Ideally the existing SecurityStore and configuration will remain for doing per-deployment keystore configuration.

          Optionally they should be able to refer to a JaasSecurityDomain, which would be globaly configured. So there would be no need to dynamically create one. This needs to be optional because we deploy against the mc, which is not necessarily jboss (could be tomcat).

          -Jason

          • 2. Re: ws-security JBWS-638 - Design Notes
            mageshbk

            According to jassSecurityDomain implementation, KeyStorePassword can be

            Plain Text
            {EXT} command
            {CLASS} command

            Now I have given these two provisions in SecurityStore as we need to be independent of the mc that we are deploying in. I was thinking to write Testcases for these two scenarios. Any idea where I can get a {EXT} command line tool and how do I integrate with our code. Should I put it as a thirdparty library? I can use the jbosssx.jar but the PBEUtils does not have a decode command line interface. Please help!

            • 3. Re: ws-security JBWS-638 - Design Notes
              jason.greene

              I would test {CLASS} using org.jboss.security.plugins.FilePassword, and you can test {EXT} by either creating a dummy implementation, or just creating a class with a main method that calls FilePassword.

              • 4. Re: ws-security JBWS-638 - Design Notes
                mageshbk

                >>>Optionally they should be able to refer to a JaasSecurityDomain, which would be globaly configured.

                In order to do this, we could use a MBeanServer code to load the global configuration and call the appropriate methods on that to do the decode, but the {CLASS} and {EXT} implementations within SecurityStore will remain as is for use otherwise.

                1. Doesn't this seem to be a duplicate code?
                2. Using MBeanServer we will have to use the org.jboss.mx.util.MBeanServerLocator, isn't this tied up to JBoss alone? It will not work on Tomcat!

                • 5. Re: ws-security JBWS-638 - Design Notes
                  mageshbk

                  As an alternative approach we can just use the MBeanServer in WSSecurityDispatcher to load the url, store type and passwords and create a SecurityStore leaving the decode option to SecurityStore. This way only the {EXT} and {CLASS} will be supported and it is transparent. Is this fine?

                  I like this approach!

                  • 6. Re: ws-security JBWS-638 - Design Notes
                    mageshbk

                    Moreover the MBeanServer approach does not expose the getKeyStorePas() and getTrustStorePass() methods, is this a viable approach?