Sorry, I may have mislead you here:
Erik Weber wrote:
Leandro, perhaps I didn't explain very well. As far as I know, there is no way for you to intercept the login request and process the j_username and j_password parameters yourself -- you have to let the container receive the form submittal and process the login. This is why I said, your login form can't be a Struts form -- your login page is basically not going to be a part of Struts. You'll have to think of your login screen as one face of a container "module" or "extension" that can serve as the front door of *any* web apps running in that container. It doesn't belong to the web app, but you can make it look like it belongs to it, since the only requirement is to have an HTTP form that delivers those two parameters to the container.
However, once the container has processed the login (the container invokes login modules that you have configured with directions on how to map users to roles in your realm -- as you did with JBoss in your login-module XML configuration), it will propagate all the users and roles, etc., to the container and make them available to components running in that container -- suddenly those methods like HttpServletRequest.getUserPrincipal and HttpServletRequest.isUserInRole actually return something you can use. Now you are querying "standard" methods that all good containers should support. That is the idea anyway. Remember that this depends on an underlying security configuration that is going to be container-specific.
I can tell you that I have not been able to use this approach when deploying web apps in the JBoss-3.2.x-Tomcat-5.0.x stack.
By "this approach" I meant making the login page be a part of Struts. But using a login page that is a simple form with an action set to "j_security_check", and the parameters set to "j_username" and "j_password" does work just fine. I was trying to make my login screen a part of Struts (with an associated form-bean, etc., as I think you are trying to do) and that's what I'm saying doesn't work, not container-managed security itself, in JBoss/Tomcat.
I tried something similar to what you are trying (I wrote a CallbackHandler, etc., -- see the JBoss free doc on JAAS by Scott Stark, or maybe you already have). The problem is that you are logging in with a JBoss login module, and there is no integration between that module and Tomcat, if I am not mistaken.
I haven't tried container-managed security with Tomcat stand alone, but I am led to believe it is straightforward.
I don't know why I even wrote this sentence, it is completely irrelevant to what we were talking about (a container-managed login that is also part of your Struts app). I got sidetracked in my thinking. I am certain that container-managed security works just fine in its own right in either container.
A possible solution, if you have to stick with JBoss, could be for you to write code that logs in with not only the JBoss login modules, but the Tomcat ones. I don't know spefically how to do this or if it can be done, but I suspect that it can, and I seen suggestions here and there on how to do it. However, I question whether it is worth the trouble. The idea here is to let the container do all this for you. Still, if you get something along these lines working, please share it, because I suspect it would be useful until such a time as JBoss and Tomcat integrate better when it comes to security. But be careful of wasting your time.
Erik
Leandro Melo wrote:
I'm back! After getting some jaas studies, i'm a little bit better, so i can now formulate a better question.
Here it is... (I know that this is not only a Struts question, because it envolves jaas, but i'm pretty sure that people over here could give me some advise on how to handle the problem).
I got my application protected with JAAS, so users cannot access any pages or servles withou a login. I build then an Action to handle login stuff.
Heres the code of my LoginAction (execute method).
//... String j_username = (String)request.getParameter("j_username"); String x = (String)request.getParameter("j_password");
if (x != null){ j_password = x.toCharArray(); handler = new UsernamePasswordHandler(j_username, j_password); } LoginContext lc = null;
try {
lc = new LoginContext("example2", handler);
lc.login();
//this part doesn't matter very much
Subject subject = lc.getSubject();
Set principals = subject.getPrincipals();
Principal user = new SimplePrincipal(j_username);
principals.add(user);
} catch (LoginException e) {
// TODO Auto-generated catch block
e.printStackTrace();
throw new Exception();
}
return mapping.findForward("index");
The above code runs perfectly! It logs the user correctly and then i'm forwared to my index page. [b]But[/b], when i get to index, everything is gone!!! I'm not logged anymore. If i try to access another page in my application, i'm redirect to the login.jsp page again!!!
I heard that this is because the multi-thread characteristic of the servlets, but How can i workaround this??? how can i make this maintain my login through the rest of my session???
Here's a piece of login-config.xml
<application-policy name = "client-login"> <authentication> <login-module code = "org.jboss.security.ClientLoginModule" flag = "required"> </login-module> </authentication> </application-policy>
<application-policy name="example2">
<authentication>
<login-module
code="org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag="required">
<!--<module-option
name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>-->
<module-option name="dsJndiName">java:/DefaultDS</module-option> <module-option name="principalsQuery">Select Password from Principals where PrincipalID =?</module-option> <module-option name="rolesQuery">Select Role 'Roles', RoleGroup 'RoleGroups' from Roles where PrincipalID =?</module-option> </login-module> </authentication> </application-policy>
Thanks and regards, Leandro
_______________________________________________________
Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! http://br.acesso.yahoo.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
