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]
