http-invoker and authentication info

[dsengupt]

"dsengupt" wrote:

"dsengupt" wrote:
Hi,
I'm trying to use the http-invoker to call EJBs from my Applet. However, it looks like everytime i try to do a JNDI lookup and call the EJB, a new Http Session is being created. So i cannot reuse my authentication and authorization info stored when the user logged into my server. I tried to pass the sessionID that i recieved just after login to the HTTP-Invoker but the request never accepts the sessionID i want, but always creates a new session. This looks like a mundane usage, where users would want to reuse the sessionID in their applet. Has anyone faced a similar problem?

[tom.elrod]

"telrod" wrote:

"telrod" wrote:
Do you have an example applet+ejb ear that demonstrates what you are trying to do?

[dsengupt]

"dsengupt" wrote:
Hi,
I've partially solved this issue. I set the invokerServletPath system property dynamically in the applet's VM to be http://...../JMXInvokerServlet;jsessionid=<sessionid>. This in addition to including the 2 servlets in my app's war allows me to share the session. However, this should have been taken care of by cookies, but despite the fact that i have cookies enabled, cookies are not included in the requests. Now due to some reason, the EJB's do not seem to get the CallerPrincipal from the invocations. I have created a couple of security filters around the InvokerServlet that does a jaas login and logout everytime i invoke an ejb method. The information for the login is obtained from the session. However, the SecurityInterceptorProxy for the bean, cannot recover the CallerPrincipal and thereby throws an "access control exception". Do we know if the contexts are being re-created during the http-invoker invocation? How can i get to see the InvokerServlet source code? Thanks for the attention.

[dsengupt]

"dsengupt" wrote:
I think i know why CallerPrincipal is incorrect(rather it is an unauthenticated user). That's probably because i'm trying to authenticate in the middle of a method invocation (in my filter where i intercept calls to the JMXInvokerServlet) whereas i really should authenticate before the call in my client. My problem relates to the fact that i have a sessionID in my applet and i want to re-use the authentication that was already performed by the web-browser. Firstly, i need to do a JAAS login that can be accomplished using my sessionID. Secondly, somehow i need to make the security interceptor in my EJBObject propagate the security identity i can obtain via the JAAS login through the security context. Any pointers to do either of the above2 will be great. Thanks.

[tom.elrod]

"telrod" wrote:
This can be handled many ways:

- If the applet is secured, bundle the invoker with applet war and
security
propagation happens automatically
- If applet is secured, enable the tomcat single sign-on added in
3.2.4RC1 codebase and security propagation happens automatically
- If the applet is not secured, specify the role the invoker servlet
uses to call the ejb using the web.xml run-as tag
- If the aplet is not secured, to a jaas login using the
ClientLoginModule
in a filter to set the security context for the call into the ejb stack
...

[dsengupt]

"dsengupt" wrote:
telrod,
thanks for the responses and pointers.

>- If the applet is secured, bundle the invoker with applet war and security
In this case the invoker does recognize the session (being in the same war), but the caller's identity was still not transferred

>- If the applet is not secured, specify the role the invoker servlet uses to call the ejb using the web.xml run-as tag
This does not transfer the authenticated user's roles but defines a role that all callers would be assigned and be able to call methods. This allows every caller to call EJB methods irrespective of the callers privileges.

>If the aplet is not secured, to a jaas login using the ClientLoginModule
The applet is secure, but doing a jaas login after the invocation has already been made does not inject the login information into the MarshalledInvocation object that has already been created.

This is what i ultimately did. I created a new servlet in my war that does exactly what the invoker servlet does except additionally, once it retrieves the MarshalledInvocation and the invocation does not have a principal, i set the SecurityAssociation.getPrincipal as the principal of the mi instance. The SecurityAssociation.getPrincipal returns the web-authenticated user's principal and setting this ensures we use this as the caller principal in the invocation to the JMX bean that redirects the call to the EJB.

Regards.

[jimbrady]

Hello,
Has a better solution to this problem been found - I have exactly the same issue. It looks like every call to method is getting a clean security framework. As I am trying to work with cookies from a batch application, it is a bit of a pain for me.

[dsengupt]

The problem as I discovered later was that during ejb invocations over http, the SecurityContext did not possess the user credentials. The default JMXInvokerServlet does not setup the security context in the marshalled invocatoin and hence the securityinterceptor on the server side of the ejb cannot determine authentication info. I solved it by setting up 2 things - firstly a filter that extracts username/password (set during login) from the httpsession and performs a jaas login(this sets up the SecurityAssociation for this thread). Secondly, instead of posting to the default JMXInvokerServlet, i post to a custom servlet that in addition to doing what JMXInovekrServlet does also gets the principal and credentials from the SecurityAssociation and sets it to the marshalled invocation (marshalled invocation is available from the http servlet request). Hope this helps.

[jimbrady]

Thanks for replying. It doesn't quite fit my case because in my case, I don't have the credentials (I just have a Tomcat Valve that extracts the user from a cookie and passes that through without a password.) But I have got the authentication to work (the invoker JNDIFactory is protected and it gets through that), the problem is that the principal is not getting to the session bean. I can't even get to the session bean if it is protected, and this connection rejection occurs before the marshalled invocation is established in the InvokerServlet. I can't understand why JBOSS doesn't have an answer to this, because one of the justifications for using HTTP tunneling is to establish the user credentials.

Only protecting the JNDI interface is rather pointless from my point of view. I want to use SSO from a java application using the cookie set up from the browser.

[jimbrady]

For what its worth, I can't find any evidence that the Servlet is being called at all. I have fairly detailed logging of the security side switched on. I see the following:

2007-05-24 15:48:39,205 TRACE [org.jboss.web.tomcat.security.SecurityAssociationValve] End invoke, callerGenericPrincipal[[e-mail]()]
2007-05-24 15:48:39,205 TRACE [org.jboss.security.SecurityAssociation] clear, server=true
2007-05-24 15:48:39,970 TRACE [org.jboss.web.tomcat.security.SecurityAssociationValve] Begin invoke, callerGenericPrincipal[[e-mail]()]
2007-05-24 15:48:39,970 TRACE [org.jboss.security.SecurityAssociation] pushRunAsIdentity, runAs=null
2007-05-24 15:48:39,970 TRACE [org.jboss.web.tomcat.security.RunAsListener] JMXInvokerServlet, runAs: null
2007-05-24 15:48:39,970 TRACE [org.jboss.web.tomcat.security.RunAsListener] JMXInvokerServlet, runAs: null

Notice JMXInvokerServlet (not my version - I wonder why) runAs null.

[dsengupt]

Every http request runs in a separate thread. The SecurityAssociation of that thread can be set via a filter(that is where you can get the user from the cookie and perform a JAAS login or call SecurityAssociation.setPrincipal - i would do it through JAAS to ensure the principal is pushed and popped in a stack). Your servlet should get this principal back (using SecurityAssociation.getPrincipal) and set the MarshalledInvocation.
One possible reason why your servlet is not invoked could be the HttpInvoker has not been configured to use your servlet. By default it uses the JMXInvokerServlet. One way to do it is to specify that the invoker URL is in a System property on the client.


{Put your property name here}

[dsengupt]

Every http request runs in a separate thread. The SecurityAssociation of that thread can be set via a filter(that is where you can get the user from the cookie and perform a JAAS login or call SecurityAssociation.setPrincipal - i would do it through JAAS to ensure the principal is pushed and popped in a stack). Your servlet should get this principal back (using SecurityAssociation.getPrincipal) and set the MarshalledInvocation.
One reason why your servlet is not invoked is because the HttpInvoker has not been configured to use your servlet. By default it uses the JMXInvokerServlet. One way to do it is to specify that the invoker URL is in a System property on the client.


{Put your property name here}

[jimbrady]

dsengupt...

Thanks for the reply, but I'm not sure I understand what you are suggesting. Because I am running as a stand alone java application (I need to do things that an applet can't), I don't have a browser to pass across cookies. I modified some of the invoker http modules to add the cookies in order to invoke the JNDIFactory. That worked via a TOMCAT Valve (similar to the one supplied for SSO) that works fine for Browser access to my Web Application.

How do I get the cookies in a filter? The filter runs on the Server and the cookies are (originally at least) on the Client. Sorry to be a pest but this is all very annoying as I can't understand why there isn't a standard solution to the SSO issue.

Has Scott Stark an opinion on this?

[jimbrady]

dsengupt...
This may help explain another aspect of my problem. My guess is that there is another client process to open a connection besides the two I have already found and I need to add the cookies to that connection as well:

org.jboss.invocation.http.interfaces.Util
org.jboss.naming.HttpNamingContextFactory

http://jboss.org/index.html?module=bb&op=viewtopic&t=108685