Are you using standard web security (by defining security constraints in the web.xml) or are you performing the Jaas login yourself?
I'm performing the JAAS login myself through a call to the LoginContext
> I'm performing the JAAS login myself through a call
> to the LoginContext
I already thought so. What happens is that when you login, only the current thread is "logged in" - and that's rather useless in a thread-pooling environment. ;-)
What you need to do is make sure the security context is set during each servlet invocation, what you can achieve by performing a jaas login on each request.
See http://www.luminis.nl/publications/websecurity.html for more explanation and code sample.
Thanks for that, that seems to have been at least part of the problem. I implemented a servlet filter as suggested in the article. I don't however do an explicit login every time because that would involve going to the database on every request, which I don't really want to have to do, so the filter simply checks in the session object to see if the user has previously logged in and if they have, it uses the SecurityAssociations static methods to bind the details of this user into JAAS.
This works fine appart from the first call to an EJB. The first call of this type throws an 'Insufficient method permissions' exception, even though the methods are all marked unchecked. Subsequent calls (if I refresh the browser for instance) in the same session seem to work just fine.
Any ideas? Currently I have bypassed to situation by simply making the first call twice, but that is obviously a less than ideal solution.
Thanks again for the help.
> I don't however do an
> explicit login every time because that would involve
> going to the database on every request, which I don't
> really want to have to do,
Sure (although the JBoss Jaas security manager will cache user credentials), but if you configure only ClientLoginModule for the filter, it will work fine, without going to the database ever.
> Any ideas? Currently I have bypassed to situation by
> simply making the first call twice, but that is
> obviously a less than ideal solution.
I think you are doing a login and an ejb call in the same servlet call, right? Because the login comes _after_ the filter, the security association is not yet set....
A solution would be to let the login be handle by a login-servlet, like in the sample code provided with the article.
> Thanks again for the help.
You're welcome. ;-)
Let me know if it doesn't work, or i misunderstood.
The login is performed in a struts action class, which forwards on to the action for invoking the index page. That action (indexActionInvoke) is second in the chain to the servlet filter (and the filter appears to be firing correctly). It is on the index page that the EJB is first accessed.
The first time I call indexActionInvoke it throws an EJBException (Insufficient method permissions), but if I then simply press f5 to refresh it seems to work just fine.
Any other ideas?
> The login is performed in a struts action class,
> which forwards on to the action for invoking the
> index page. That action (indexActionInvoke) is
> second in the chain to the servlet filter (and the
> filter appears to be firing correctly). It is on the
> index page that the EJB is first accessed.
If that forwards is a sort of "server redirect" (and from the description, i think it is) the filter is not passed between login and ejb-call, which would explain why you get this behaviour (the filter is only called once for each http request).
If this is the case, you could change it to a client redirect (forcing an extra http request, which does pass the filter), or code something similar as the filter in you login-action...
thanks for the reply but it appears that the redirect from the login page works, it is the one after that (i.e. going from the index page to some other page that breaks). So it definately is going through the filter and in some cases the filter works and in other cases it doesn't
Just a quick note to close this thread. I've solved the problem but I don't exactly know what I did. I tidied up the code in the Filter and it now no longer throws exceptions on the first try.
I assume that there was a buggy line of code in there somewhere but the general approach seems to work just fine.
Thanks again for your help Peter.