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
>
>

Reply via email to