Rob et al.--
LDAP is attractive to me because it's where your regular,
already-being-maintained (LAN, whatever) user database is likely to reside
(Exchange, Notes, whatever, with LDAP interface.)
LDAP supports various password/credential schemes: I don't quite understand
why you can't pump in your legacy ones in in a batch anyhow (unless they are
already digests.)
As far as different credentials, I tink there are 2 ways to go: LDAP group
entries (which are designed reasonably well for maintenance by an
administrator) which might also be treated as roles (mapped to J2EE app
roles); and signed or unsigned attributes (additional credentials) in the
user's entry itself. Thus one has a single identity (good for
single-signon!) with multiple credentials.
I haven't seen much of this in action, but it seems the facilities are
there.
Martin
Rob Tanner wrote:
> Allen,
>
> LDAP is sometimes a viable solution and sometimes not. It's a
> direction I am already moving and most of the infrastructure is in
> place. The problem is I have 3000+ accounts with legacy passwords.
> The LDAP server uses, I believe, a SHA-1 digest for passwords.
> Therefore, moving from the SQL database to LDAP is not transparent and
> requires that same 3000+ users to do something in order to make it
> happen. Even if the something is as simple as a web page where they
> enter their username and password and then simply press the submit
> button, getting 3000+ users to do it without generating a lot of flak
> and ill feelings requires time and carrots. And besides, your
> suggestion only addresses using the SQL database for authentication
> credentials, it doesn't address the myriad of other applications that
> might access a SQL database, and do so under an application specific
> user name (again, it is easier and I think less error prone to keep the
> grant table entries to a minimum -- let the application use an
> application specific user id and let individual users present their
> personal credentials to the application, not the database). So even if
> a user authenticates him or herself via LDAP, the issue of securing the
> applications db access credentials remains.
>
> Sticky problem, ain't it!!
>
> -- Rob
>
> --On Saturday, March 03, 2001 11:53:05 PM -0600 Allen Akers
> <[EMAIL PROTECTED]> wrote:
>
> > My suggestion would be to use an LDAP database as your authentication
> > database for your individual users. You can authenticate that person
> > and then access information about their database access group and the
> > associated group password, if you set up the LDAP database correctly.
> > In this way, the user doesn't need their own SQL user account, just a
> > valid LDAP entry tied to a generic user group and no type of sensitive
> > information need reside on your machine running Tomcat. There are
> > some other ways you could do it, but that is probably the most
> > versatile and straightforward.
> >
> > Allen Akers
> > Programmer Analyst
> > Strategic Web and Voice Development
> > ________________________________
> > [EMAIL PROTECTED]
> >
> >
> >>>> [EMAIL PROTECTED] 03/03/01 05:03PM >>>
> > Adam,
> >
> > It's not really a Tomcat issue, but one of the things that's covered
> > sometimes poorly and sometimes not at all is thread synchronization.
> > Unless you're using th SingleThreadModel interface, that's a serious
> > issue for servlet programming, and unless you're familiar with
> > threading in Java you can get yourself in all kinds of trouble
> > (writing
> >
> > servlets was my first exposure to Java and I wasn't at all familiar
> > with threads, and I suspect there are a lot of others who have gotten
> > caught off-guard like that). Though it's not really a Tomcat issue,
> > it
> >
> > would be a valuable appendix.
> >
> > The other area that drives me crazy (and I still haven't found any
> > satisfactory mechanisms) is how to secure credentials the servlet
> > needs
> >
> > to access database resources. For instance, if a user's credentials
> > are stored in a MySQL database, the servlet must access that database,
> >
> > and to do so, it needs a valid uname and password. These would not
> > normally be the uname and password passed in from the request object
> > (assuming some variety of forms based authentication) since you don't
> > normally have hundreds or even thousands of users setup with database
> > privileges. Rather, the servlet uses it's own credentials to access
> > the database and retrieve the user's specific credentials stored in an
> >
> > ordinary table. The problem is that web.xml is not a secure place to
> > store the servlet's credentials, especially if you're running Tomcat
> > on
> >
> > a UNIX machine with many applications and many developers, not all of
> > whom should have access to the particular servlet's credentials. I
> > have asked that same question on several different venues, but the few
> >
> > answers I've gotten have all been non sequitur, and I think that's
> > because the question has not been fully understood. A discussion of
> > issues like that (especially for folks coming from an apache/cgi world
> >
> > where good solutions are well-known) would be very valuable.
> >
> > Beyond that, if you need readers or folks to beta test examples and
> > procedures, I'd be more that happy to help out.
> >
> > -- Rob
> >
> >
> > --On Saturday, March 03, 2001 02:51:35 AM -0600 Adam Fowler
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Hi all,
> >>
> >> I will shortly be writing a book for Sams Publishing in a similar
> >> format to the recently released(and well received) book on Python.
> >>
> >> I currently have the task of writing a proposal for content of the
> >> book. The book's target audience is web developers who will be using
> >> Tomcat. It will be based on Tomcat 4.0, but will also be useful for
> >> Tomcat 3.x.
> >>
> >> I am e-mailing this list to ask for serious suggestions for sections
> >> of the book. From installation through configuration to deploying
> >> custom applications.
> >>
> >> Any help would be appreciated and would benefit everyone as this
> > book
> >> is meant to be for you people.
> >>
> >> If any Tomcat User Group(TUG) members wish to write user
> >> documentation for Tomcat (The 'paths' that have been discussed) then
> >> drop me an e-mail and maybe we can help each other.
> >>
> >> Regards,
> >> Adam.
> >>
> >> ----
> >> Adam Fowler
> >> Second year Computer Science undergraduate
> >> University of Wales, Aberystwyth
> >> Carroll College, WI, USA(2000-2001)
> >> web: http://gucciboy.dyndns.org/aff9
> >> e-mail: [EMAIL PROTECTED]
> >> "Every new beginning comes from some other beginning's end"
> >> ----
> >>
> >>
> >>
> >>
> > ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, email: [EMAIL PROTECTED]
> >>
> >
> >
> >
> >
> > _ _ _ _ _ _ _ _ _ _
> > /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> > /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> > /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> > /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> > /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> > \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
> >
> > Rob Tanner
> > McMinnville, Oregon
> > [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> _ _ _ _ _ _ _ _ _ _
> /\_\_\_\_\ /\_\ /\_\_\_\_\_\
> /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
> /\/_/__\/_/ __ /\/_/ /\/_/ PROFUNDUM VIDITUR
> /\/_/_/_/_/ /\_\ /\/_/ /\/_/
> /\/_/ \/_/ /\/_/_/\/_/ /\/_/ (Whatever is said in Latin
> \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
>
> Rob Tanner
> McMinnville, Oregon
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
