On Mon, Oct 12, 2009 at 11:03 AM, André Warnier <a...@ice-sa.com> wrote:
> Josh Gooding wrote: > ... > >> >> Andre, your talking about something like Active Directory for Windows >> Domain's to use with say Communicator, Outlook, etc, across windows >> environments with domain authentication? >> > Yes, although Windows domain authentication is not the only game in town. ** I know Andre, it was just the first thing that popped into my head. The shop I work for is a Microjunk shop and I am the only dinosaur who codes on OS platforms here after I leave they can claim to be an all .NET shop. However, i'm the only one working on programs that are making the company money... :: shrug :: anywho. I know there are others, WIndows is just one of the most commonly recognized. You also have raduis, NIS, and if I am not mistaken even LDAP. > > > I understand what the Tomcat's and > >> most org's SSO means, but I am trying to translate into something that I >> can >> talk about and not have a huge amount of keystrokes in typing. >> >> And I suggest that you to think this through from the beginning, and not > rush into a Tomcat-only authentication, if your users for instance are going > to get weary very quickly to have to login (again!) each time they want to > access this application on this host. > The other snag is if in order to do your type of authentication you need to > have your own store of user-id's and passwords. User-id's are usually OK > (they can be the same as the user's usual login), but to get a network admin > to give you the users passwords, so that you can store them in your own > Tomcat-only store, is going to be more tricky. > (Users do not, as a rule, like to have to remember several passwords). > > There are basically two types of authentication usable in Tomcat : the > container-based authentication of which mainly question so far, and the > "servlet filter" based authentication mechanisms. > These consist of wrapping all your to-be-protected webapps in a servlet > filter, which authenticates each request before it even gets to your webapp. > Servlet filters are defined at the Servlet Spec level, so are portable. To > the webapp, it is transparent. It just finds an authenticated user whenever > it runs. The filter itself determines what kind of authentication happens, > using which back-end etc.. > Here are two examples : > http://securityfilter.sourceforge.net/ > http://www.ioplex.com > Reading their docs should give you some material to think about. > > There exists a 3rd way : if you have a webserver in front of Tomcat (IIS or > Apache), they can do the user authentication, and via mod_jk (*) pass an > authenticated user-id to Tomcat (roles is another story). > > (* : plus, for Apache only, mod_proxy_ajp) > > In any case, I don't really think that you will need to create new code. > There are enough ready-to-use solutions floating around that this should be > unnecessary. And, as some people already indirectly pointed out, coding AAA > and doing it right can be very tricky. > ** I already removed httpd from the server and am very reluctant to reconfigure / install it. I'll look into those and check. Thanks man, this project is really opening my eyes to a lot of other things that I would have never thought of. > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >