Client remote Authentication using JAAS and EJB Access

Question

Hi,
I have a problem using JAAS in combination with Sun One Appserver 8.1 and a java remote client trying to access an EJB. Here is the scenario:
I have implemented an EJB who's methods are protected through the deployment descriptor:
        <assembly-descriptor>
             <security-role>
                <description>role for clients outside of the server </description>
                <role-name>sedna</role-name>
              </security-role>
            <method-permission>
              <role-name>sedna</role-name>
              <method>
                <ejb-name>ServerInfoBean</ejb-name>
                <method-intf>Remote</method-intf>
                <method-name>*</method-name>
              </method>
            </method-permission>
            <method-permission>
              <unchecked/>
              <method>
                <ejb-name>ServerInfoBean</ejb-name>
                <method-name>getVersion</method-name>
              </method>
              <method>
                <ejb-name>ServerInfoBean</ejb-name>
                <method-name>create</method-name>
              </method>
            </method-permission>
        </assembly-descriptor>I've deployed the EJB in a jar file which was packed into an ear file of a bigger application. The role has been mapped to the admin Principal in the sun-ejb-jar.xml descriptor.
I can find the EJB, create it, and call the unchecked method getVersion and that works fine, so far so good.
But then I try to access another method which is protected and then I get this exception
org.omg.CORBA.NO_PERMISSION:   vmcid: 0x2000  minor code: 1806 completed: Maybe
        at com.sun.enterprise.iiop.POAProtocolMgr.mapException(POAProtocolMgr.java:179)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:853)
        at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:137)
...I have to mention that I do make a login via the LoginContext. My jaas.config File has a reference to the com.sun.enterprise.security.auth.login.ClientPasswordLoginModule module.
After login (which works perfectly) I lookup the context with a corbaname url which - if I understood it right - ignores the Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS settings.
After that I make the calls to the EJB. And I am allways ANONYMOUS on the server side, which is definitely the problem. Because ANONYMOUS is not allowed to call the protected EJB Methods. But I made a jaas login in advance. So where am I making a mistake???
Am I doing something wrong?
Need help! Thx,
Stephan

Answer 1

Hi.
I understand correctly that you call Subject.doAs on
the client to call the remote EJB. I guess It isn't
right way.I had also a bad feeling about this, so I forget it. But anyway it wasn't working with or without using that doAs().
>
>
Subject contextSubject =
Subject.getSubject(AccessController.getContext());
contextSubject.getPrincipals();This code throws exceptions in the Appserver. Unfortunately they are catched somewhere so I'm unable to find out what was going wrong. But I guess, that these exceptions where security exceptions. Never the less thanks for the hint!
But I don't think that doing the check on the server side is the way I want to go because that is programmatically security and I want to use the declarative security which can be used through the deployment descriptor. If used correctly - and supposed I do not completely misunderstand the specification - then it should be possible to create an EJB that is protected via it's deployment descriptor and access it through the client only if the client has been authenticated through JAAS mechanisms. After successful authentication the principal should be accessible through the EJB context but not for security check, that should allready been done at this time.
Unfortunately I don't find any resource on the internet describing the scenario in such a detail that I can reproduce it. There are only very high level documentations and hints in forums.
Again, thanks for your effort,
Stephan