OK, thanks, Marc. I'm using Oracle, and it inded does seem to be case-sensitive.
I've added a role_name of the word risk, rather than RISK. Anything I had in caps like SENIOR or MGMT seemed to really throw a wrench in the login attempt. When entering this new account created, I currently am only getting an incorrect login, meaning that the db table hasn't immediately recognized the account yet, or maybe the caching is holding it up, which may be a pretty safe bet. Thanks, guys! -----Original Message----- From: Marc Farrow [mailto:[EMAIL PROTECTED] Sent: Friday, August 18, 2006 9:27 AM To: Tomcat Users List Subject: Re: Security constraint/login form Valid roles are whatever are defined to be valid. The specific name does not matter. But if you are using a Database for validation, then the roles are pulled from the database column that you have associated as the "roles". Depending on your database, they may or may not be case-sensitive (the values that is). On 8/18/06, Propes, Barry L <[EMAIL PROTECTED]> wrote: > > Looking at the 4.1 doco, it states about the JDBC Realm and user tables > configuration: > > "Role name of a valid role associated with this user" > > > So then I ask, what's a valid role? What are the choices? Is valid ONLY > service or admin? > > -----Original Message----- > From: David Smith [mailto:[EMAIL PROTECTED] > Sent: Friday, August 18, 2006 6:26 AM > To: Tomcat Users List > Subject: Re: Security constraint/login form > > > Over an hour? Not even ODBC has that kind of latency. Could you be > looking at a caching issue? > > --David > > Propes, Barry L wrote: > > >ok, thanks..I think there's a fair amount of latency between my database > query info and what's actually updated in there. > > > >Something I'd changed over an hour ago was still showing the old value, > and could have been causing some of the problems. > > > > > > > >-----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 > >> > >> > >> > > > > > > > > > > > > > --------------------------------------------------------------------- > 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
