never mind...sorry, I did see it in the web.xml file under the role-name element. Sorry about that!
-----Original Message----- From: Propes, Barry L Sent: Monday, August 21, 2006 10:43 AM To: Tomcat Users List Subject: RE: Security constraint/login form Ok, I'm finding that the names are somewhat relevant. For instance, if I assign a user the role service, or admin, it works with no problems. If I assign another name -- say senior, or legal or business -- it does not work. Any ideas why? And, if it's limited to this by Tomcat's default security constraint class files, can I individually edit and recompile them, and then it will redeploy in the war file upon restart? -----Original Message----- From: Marc Farrow [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 4:03 PM To: Tomcat Users List Subject: Re: Security constraint/login form The names are irrelevant. They just have to match between implementation and setup. On 8/17/06, Propes, Barry L <[EMAIL PROTECTED]> wrote: > > quick answer is yes to they have to be service or admin or yes to I can > declare them anything that matches the column in another DB table I've > created or yest to my last question about the values being what I want? > > -----Original Message----- > From: Marc Farrow [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 17, 2006 3:38 PM > To: Tomcat Users List > Subject: Re: Security constraint/login form > > > Quick answer is yes. > > On 8/17/06, Propes, Barry L <[EMAIL PROTECTED]> wrote: > > > > I wonder though...do the role_names have to be service or admin or > > something like that? > > > > Can they be anything I declare them to be that matches the column in > > another DB table? > > > > i.e. > > I've got user_name and role_name as columns in the user_roles table. > > > > Can I make a 3rd table also having a column called role_name, but with a > > value such as RISK, author, legaldept, etc.? > > > > -----Original Message----- > > From: Marc Farrow [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 17, 2006 2:11 PM > > To: Tomcat Users List > > Subject: Re: Security constraint/login form > > > > > > Are you talking about the tomcat-users.xml file and the roles defined in > > there? > > > > The security-contraints are pretty flexible and you can use any number > of > > ways to define your realms. If you look at the web.xml for the manager > > application (that is shipped with Tomcat), you can see how that realm is > > defined and used. You can even use encrypting on the passwords in that > > file. If you don't mind maintaing that file for roles and users, then > > just > > modify it to fit your needs and change your security contraint for your > > web > > application to match those roles. Below is a quick example. If you are > > wanting something for flexible, then you can research and use your > > favorite > > database for authentication or even your favorite LDAP. Below is a > quick > > example of how to use a user-defined role in the tomcat-users.xml file > and > > how to match it to two different URLS in one web app. > > > > Please understand, this is just a quick example and I do not dare > declare > > that this will work. Just a springboard to help you get your feet wet. > > > > > > tomcat-users.xml: > > > > <tomcat-users> > > <role rolename="role1"/> > > <role rolename="role2"/> > > <user username="user1" password="userpass1" roles="role1,role2"/> > > <user username="user2" password="userpass2" roles="role2"/> > > </tomcat-users> > > > > application's web.xml: > > > > <security-constraint> > > <web-resource-collection> > > <web-resource-name>Restrict to role1 and role2/> > > <url-pattern>/welcome.jsp</url-pattern> > > </web-resource-collection> > > <auth-contraint> > > <role-name>role1</role-name> > > <role-name>role2</role-name> > > </auth-contraint> > > </security-contraint> > > > > <security-constraint> > > <web-resource-collection> > > <web-resource-name>Restrict to role2 only/> > > <url-pattern>/other.jsp</url-pattern> > > </web-resource-collection> > > <auth-contraint> > > <role-name>role2</role-name> > > </auth-contraint> > > </security-contraint> > > > > <security-role> > > <description>some descr</description> > > <role-name>role1</role-name> > > <role-name>role2</role-name> > > </security-role> > > > > > > On 8/17/06, Propes, Barry L <[EMAIL PROTECTED]> wrote: > > > > > > to add to my question earlier below, would it be something as simple > as? > > > > > > String juser= (String) request.getAttribute("j_username"); > > > > > > Granted I have no idea what the session attribute is under the hood, > > only > > > know that j_username is the input name for the user_name. > > > > > > I was thinking with that info, I could then run a select query to > > extract > > > the role_name from an additional joined table to authenticate a step > > > further. Does what I am explaining make sense? Forgive me if not. > > > > > > When I say additional table, I mean one in addition to the user_name > and > > > user_roles table that Tomcat requires for the form login security > > constraint > > > to work. > > > > > > > > > > > > -----Original Message----- > > > From: Propes, Barry L > > > Sent: Thursday, August 17, 2006 11:13 AM > > > To: Tomcat Users List > > > Subject: Security constraint/login form > > > > > > > > > I realize that in Tomcat (I'm using 4.1.3 and 4.0.1 by the way -- a > > > version on a prod. server and one ony my desktop) that you can create > > the > > > simple table titled users and configure it in the server.xml file and > > then > > > likewise configure the web.xml file's security constraint properties. > > > > > > My question is, can you add other columns to the table and then do a > > join > > > on another table as to further enhance security? > > > > > > If so, what is involved, and how involved is it? > > > > > > Thanks! > > > > > > Barry > > > > > > > > > --------------------------------------------------------------------- > > > To start a new topic, e-mail: users@tomcat.apache.org > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Marc Farrow > > > > > > -- > Marc Farrow > -- Marc Farrow