Excellent reply :) I guessed to write a customized UserDatabase just because it was there in the server.xml, and indeed it took me some hours :(
On Apr 9, 2005 10:46 AM, Bill Barker <[EMAIL PROTECTED]> wrote: > Yeah, but writing your own custom UserDatabase is usually harder than > writing your own custom Realm (at least four classes vs. one.). It does > have the advantage that (in theory) it should work with the admin webapp > ;-). > > Custom Realms really aren't all that hard. You typically create a class > that extends RealmBase > (http://jakarta.apache.org/tomcat/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/realm/RealmBase.html, > changing the '5.5' to the TC version you care about, unless it's 3.3 where > the package is different). Then you override the 'getPassword(String)' > (returns the db-password of the user), the 'getPrincipal(String)' (returns > the userPrincipal for the user), and the 'getName()' (returns the name of > the realm -- any identifying string). If you return anything but a > o.a.c.realm.GenericPrincipal from getPrincipal, then you'll have to override > the 'hasRole(Principal, String)' method as well. > > One strategy is to just do the above, and you are done. The other is to > implement the required overrides (except 'getName') to return null, and > override the 'authenticate(String, String)' method. Whichever works better > with your DB. > > "Jerome Jar" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >I think you can modify the "UserDatabase" part in server.xml, to > > change the authentiation to use in your own way. > > > > On Apr 9, 2005 1:41 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > >> The only exposure that I have to this is configuring tomcat-users.xml so > >> I > >> can use the manager webapp, so please bear with me. > >> > >> I've got several web front-ends for a non-JDBC database. There is a > >> 'green > >> screen' (telnet) app running against the DB that uses a system of user > >> security classes to which different 'screens' are assigned. That data is > >> stored in the DB itself. We've fit the web front end into this system by > >> assigning each 'page' of the webapp a 'screen id', so that the admin can > >> define who sees what in a single place. > >> > >> What I'm wondering is if there's any hope of using this data with the > >> existing request.isUserInRole() method. (The security classes are > >> (loosely) > >> roles.) I only need to deal with authorization. Authentication is > >> handled > >> separately by a Filter that redirects elsewhere to make them log in. > >> > >> Can someone point me in the right general direction? Everything Google > >> turns up starts in with configuring a JDBC or JNDI realm, and I don't > >> think > >> that part of it will ever work with this database. Would I end up > >> defining > >> my own kind of a Realm? > >> > >> Confused, > >> -- > >> Wendy Smoak > >> > >> --------------------------------------------------------------------- > >> 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]
