This is certainly a strange way to do container managed authentication. Several things come to mind that may prevent you from doing this. First, I think the j_security_check request must use POST method. Second, I suspect that your jsessionid would need to be a valid session id. Third, I think Tomcat has a way to track sessions that is partly based on IP address of caller, so this would not work.
All in all, this just seems to not be the way to go. Tell us what you are trying to do, maybe we can suggest other options.
I try doing similar things and I'm stuck, too ;-(
In a way I'd like to replace j_security_check - Unfortunately I can't find the source code of that servlet ...
This is my first trial:
A backing bean creates a LoginContext and uses the security-domain I specified in login-config.xml (with DatabaseServerLoginModule) and the AppCallbackHandler (I just tried that one, perhaps it is the wrong one?). The authentification succeds, but what do I do with the Subject I got from loginContext.getSubject() ?
Can I set it anywhere into a jboss-security Class? Do I have to cast it to something else? To get the Roles out of it?
Is everything much more complicated than I thought ? ;-)
You are confusing container managed authentication with application managed authentication. The "j_security_check" resource is defined by the Java Servlet spec. as a resource that must be made available to applications to provide conainer managed (form-based) authentication. It can not be replaced. Please see JBoss server guide http://docs.jboss.org/jbossas/jboss4guide/r5/html/ch8.chapter.html and http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossSX on how to set up container managed security in JBoss/Tomcat.
That said, you have described application managed authentication. Creating a LoginContext, and authenticating a user in your application is perfectly acceptable. However, the result then is only known to, and must be managed by your application. You can not then hand the result over to the conatainer to manage.
good luck, cgriffith
Thank you for replying, cgriffith!
Do you say that tomcat authentication (I know it quite well, just starting to switch to ejb) is the only way for jboss to remember Principal and Roles to do further security checks (as @RolesAllowed and things like myfaces "visibleOnUserRole" - ok, that's really web-dependent)?
But then what about non-webapp-clients? How does a Swing client, for example, do a login to then use jboss security restrictions? Again for every bean method call? Is it a the "session" problem?
The reasons I want to switch off tomcat auth.:
a) I want to set up a full-fledged user entity when loggin in
b) I tried to use a LoggedInInterceptor that forwards/redirects to some "login", but with tomcat-auth, you always must send the user to some other secured page and then to intercept that somewhere else to get the rest of the user data.
c) There is no FacesContext on these login form pages, so these pages
d) There is no FacesContext and no SeamContext in a Servlet Filter
e) same problem in a custom LoginModule (that was my first idea...)
Hello Sonja and cgriffith,
thanks for your replies.
yes - its a strange way to do a programmatic login but
i didn't found another way...
Authenticating via creating a LoginContext is the right way (and i tried it) but I need to propagate the principal through request.getPrincipal(). I need this because I'm using JBoss Portal and it's an elegant way to propagate the principal to portlets which are not in the same .war file.
A function like request.setPrincipal would be nice :-)
Maybe there is a way overriding the org.jboss.web.tomcat.security.FormAuthenticator class ?
You need to hit a secured resource and allow the container to forward you to the login page. You cannot try to do the j_security thing yourself, unless there has been a redirect.
i will try to call the j_security thing after the server send
me a redirect. maybe this will try my problems with my
url = "http://localhost:8080/portal/j_security_check?jsessionid=0000" + sessionId() + ":-1&j_username=" + getLoginName() + "&j_password=" + getPassword()";
Isn't there a way to set the principal into the request after a calling the LoginContext
Yes, you could create your own custom Authenticator for Tomcat. See:
Specifically you might want to look at the the AuthenticatorBase.invoke() method.
Thanks for this hint,
this seems to be the right way, i will try it soon.