6 Replies Latest reply on Aug 4, 2003 5:43 PM by bdai123

    Authentication. Again.

    Tarek Hammoud Novice

      Hello,

      We have an EJB that we exposed as a web service using JBOSS-NET. When the EJB's do not belong to a security domain (i.e unsecured), things work perfectly from Java, C# and Excel VB clients.

      When the EJB's are secured, we start getting authentication errors like:

      java.lang.SecurityException: Authentication exception, principal=null
      at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:162)
      at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:81)
      at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:120)
      at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:93)
      at org.jboss.ejb.StatelessSessionContainer.internalInvokeHome(StatelessSessionContainer.java:310)
      at org.jboss.ejb.Container.invoke(Container.java:694)
      ...
      ...

      The Java client sets the user name / password using the following code:

      binding._setProperty(Stub.USERNAME_PROPERTY, "xyzabcd");
      binding._setProperty(Stub.PASSWORD_PROPERTY , "xyzabcd");

      The tcpmon clearly shows an Authorization: entry in the HTTP
      request. However, it looks like the EJB layer does not see a valid , non-null , principal.

      We changed the security domain from 'other' to the same domain of the EJB's but we had the same exception. The following files were changed: jboss-web.xml axis-config.xml.

      find . -name '*.xml' -exec grep -il 'other' {} /dev/null \;

      returns nothing.

      We also added:





      to login-config.xml.


      This is an internal application. We do not want to use SSL or anything complex.

      Can someone please point out to what we are missing ?

      We are using JBOSS-3.2.1 beta. We cvs checked out the code and build it.

      Thanks you very much.
      Tarek Hammoud
      Chicago, IL

        • 1. Re: Authentication. Again.
          Tarek Hammoud Novice

          >>We also added:

          >>>type="java:org.jboss.net.axis.server.JBossAuthenticationHandler">
          >>
          >>
          >>to login-config.xml.

          Please ignore the above statement. I just meant to say that I changed it in axis-config from 'other' to 'rcm'

          When trace is on I can see the HTTPAuthHandler printing out the user name and password that were sent to the server. It is just that the EJB security domain can not see them.

          Thanks,
          Tarek Hammoud
          Chicago, IL

          • 2. Re: Authentication. Again.
            Tarek Hammoud Novice

            Found the problem. A developer must associate a security domain with the service. In xdoclet it is done via:

            @jboss-net.authentication
            domain="yourSecurityDomain"

            Tarek

            • 3. Re: Authentication. Again.
              felix_pardos Newbie

              Would be possible to send us a C# client example with authentication that connects with EJB service that belongs to a security domain ( in JBoss 3.2.1 / JBoss Net).
              We have been unsuncessfully working on this a lot of time.
              Best Regards,

              Felix.

              • 4. Re: Authentication. Again.
                nanda Newbie

                Can you please post your build.xml for the xdoclets which generated web-service.xml Because I have tried everything I can think of and jbossnet tag does not work within ejbdoclet tag.

                Thanks
                nandamv

                • 5. Re: JBossnet ejbdoclet subtask
                  darrellvteague Newbie

                  For those out there who are trying (perhaps in vain) to get Ant/Xdoclet and JBossnet to happily work together to create web-service deployments (assuming stateless session EJBs with local interfaces on the backend), I have some information that may help. Note that this applies to the JBoss 3.2.1 with Tomcat 4.1.24 distribution. I do not know about other configurations.

                  What I found that works and/or what you need:

                  1) Patience. (Just kidding)
                  2) XDoclet 1.2.0b2
                  3) Ant 1.5.3

                  4) A stateless session bean with the following XDoclet class tags (example):

                  * @ejb:bean name="SomeSession"
                  * display-name="SomeSession Bean"
                  * type="Stateless"
                  * transaction-type="Container"
                  * jndi-name="ejb/SomeSession"
                  *
                  * @ejb:home generate="local,remote"
                  * local-class="com.yourdomain.ejb.interfaces.SomeSessionHomeLocal"
                  * remote-class="com.yourdomain.ejb.interfaces.SomeSessionHomeRemote"
                  *
                  * @ejb:interface generate="local,remote"
                  * local-class="com.yourdomain.ejb.interfaces.SomeSessionLocal"
                  * remote-class="com.yourdomain.ejb.interfaces.SomeSessionRemote"
                  *
                  * @jboss-net.web-service urn="SomeService" expose-all="true"

                  5) An Ant build.xml script with a target like this (based on the one provided in the JBoss paid-for doc):

                  <!-- =================================================================== -->
                  <!-- Generates the necessary EJB classes and deployment descriptors -->
                  <!-- =================================================================== -->





















                  <!-- AS 4/29/02 Do not validate XML files because JBoss 3.0 message driven will
                  report an wrong error because it uses the wrong jboss.dtd -->





                  Note: Substitute brackets with curly braces in the above (forum doesn't like curly braces for some reason)

                  Note: Be sure that in your Ant build.xml script, you put every xdoclet jar in your xdoclet.path like:





























                  Note: Your xdoclet.home should point to the 1.2.0b2 version of xdoclet (and all of the jar names have changed since 1.1.2).

                  Finally, note that I am actually still having issues with the jbossnet subtask (tag) in that it is generating bad interface names (duplicating the ejb bean class name) in the web-services.xml file. I cannot find documentation or source on the JbossNetSubTask class so I do not even know what all of the valid tag attributes are. I suspect that there may be an option here for specifying interface names/patterns but that will apparently require some trial and error.

                  If anyone has doc on the jbossnet ejbdoclet subtask, please let me know via a forum posting reply to this topic. Thanks.

                  • 6. Re: JBossnet ejbdoclet subtask
                    bdai123 Newbie

                    I've also been able to fully automate my code generation and build process with JBoss and XDoclet. Very slick!

                    Unfortunately, I'm encountering the exact same problem "darrellvteague" observed. The jbossnet subtask tag is generating corrupted interface names in the web-services.xml file. Specifically, the beanJNDIName value concatenates the ejb name twice.

                    Here's my XDoclet snippet (as far as I remember):

                    * @ejb.bean type="Stateless"
                    * jndi-name="basic"
                    * display-name="Instance of Basic"
                    * local-jndi-name="basicLocal"
                    * view-type="both"
                    * transaction-type="Container"
                    * @ejb.util generate="physical"
                    * @jboss-net.web-service urn="basic"
                    * expose-all="true"
                    * scope="session"

                    After some research, I noticed that specifying ejb.bean view-type attribute to "local" corrects the beanJNDIName value problem. This works fine if one will only use Web Service access to the component. Unfortunately, this doesn't help if one needs remote access to the EJB Session bean directly ...

                    Any suggestions?

                    Thanks!