4 Replies Latest reply on Mar 26, 2009 12:34 PM by Alex Sorkin

    Kerberos, ejb, rmi

    ruhe inc Newbie

      Hello.

      I'm trying to develop a swing desktop application which uses EJBs deployed on jboss.
      The connection should take place on secure channel using kerberos.
      From all the posts I found on this forum, I understood that I have to implement some steps:

      1. Need to get jboss tgt from kerberos. No problems here, I declare a new application-policy in login-config.xml and use Krb5LoginModule. JBoss successfully authenticates to kerberos and receives tgt.
      2. As I understood, on second step I have to create my own LoginModule (I looked at sources of security-negotiation-2.0.3.GA). Here is my problem. To accept security context I need to access rmi socket factory, and jndi socket factory (jndi lookups must be secure too).
      3. Third step would be just declaring a new application-policty in login-config.xml using my new LoginModule, and specify this policy for my ejb. Am I wright?

      This is server side. The same problems on client side.
      1. No problems, if I want to receive tgt. But I need to receive a service ticket, I need to establish security context. Should I use custom RmiSocketFactory implementation?


      If someone had such problem, tell me please what I need to do.

      Thanks.

        • 1. Re: Kerberos, ejb, rmi
          Anil Saldanha Master

          There is JBossNegotiation that does the kerberos stuff for the web layer. There is plan to do it for EJBs/ws etc.

          • 2. Re: Kerberos, ejb, rmi
            Alex Sorkin Newbie

            I think where are some good reasons for you to switch the protocol.

            Where is no standard implementations and I think specification for RMI to handle kerberos negotiation.

            In addition I had couple of problems to get RMI working in cluster environment behind LB.
            Actually I didn't got it working... maybe it failed just because WebsFear as client and server....

            I'm trying JBossRemoting to get "RMI over HTTP".
            This could be a standard way for kerberized remote EJB invocation.

            Also it is a good choice for you to use REST like invocation from java desktop application.
            And wrap the EJB invocation inside restlet.

            RMI protocol need be deprecated... To my opinion.

            • 3. Re: Kerberos, ejb, rmi
              ruhe inc Newbie

              Hi, alexanders.

              It's a good idea to use HTTP for rmi invocations to enable kerberized authentication.

              If you have problems with HTTPInvoker, so here is my config:

              path: JBOSS_HOME/server/default/deploy/http-invoker.sar/META-INF/jboss-service.xml
              
               <mbean code="org.jboss.invocation.http.server.HttpInvoker"
               name="jboss:service=invoker,type=http">
               <attribute name="InvokerURLPrefix">http://</attribute>
               <attribute name="InvokerURLSuffix">:8080/invoker/EJBInvokerServlet/</attribute>
               <attribute name="UseHostName">true</attribute>
               </mbean>
              


              And you'll find in docs how to customize invoker for ejb.


              • 4. Re: Kerberos, ejb, rmi
                Alex Sorkin Newbie

                 

                "ruhe" wrote:
                Hi, alexanders.

                It's a good idea to use HTTP for rmi invocations to enable kerberized authentication.

                If you have problems with HTTPInvoker, so here is my config:
                ....
                And you'll find in docs how to customize invoker for ejb.


                Actually the invoker configuration is not a problem.
                The key is configuring the invokers war web.xml to apply kerberized security constraint on InvokerServlet.
                This not quite for me to do changes in framework core.
                I'm looking for a wrap way.
                Maybe running invoker core mbean within my own application.
                And applying the security constraint inside my own deployment unit...
                Thanks to new MC...