Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-user@jakarta.apache.org
Message-ID: <3B41A20F.9020105@claudia.dyn.dhs.org>
Date: Tue, 03 Jul 2001 22:44:31 +1200
From: pete <pete@claudia.dyn.dhs.org>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19-10mdk i686; en-US;
 m18) Gecko/20010119
MIME-Version: 1.0
To: tomcat-user@jakarta.apache.org
Subject: Re: Programmatic security with servlet mappings in tomcat
References: <086757ACB14DD211A2B900805FBB0B8D07A4FADA@OSL01>
 <3B40FCF6.9030005@claudia.dyn.dhs.org> <3B4182E9.8464CDC@teamware.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sure, one is that i want custom login screens, another is that we store 
all our authentication details centrally and query for them via an XML 
data service.

Various user and domain-specific data, including user preferences,roles 
etc. is stored in this repository, not just 'yes, this user has blanket 
access to the site'.

Our permissions-management tools are all written to work with this, so i 
have an existing system i must fit my tomcat-based solutions into here.

I do use tomcat's basic authentication facilities for some unrelated 
services, but for us it makes a lot of sense to centralize 
authentication and preference data this way.

If someone writes an app that doesn't protect the page? well, then the 
page is unprotected.

Security never comes completely for 'free', and in my experience it is 
beneficial to place some onus on the developer to at least think about 
security during the course of development.

YMMV, of course, but this approach has worked well for us.

-Pete

> Pete,
> 
> 
> Interesting that you don't use the container's authentication mechanism
> to protect pages.  What if someone writes an app that doesn't protect
> the page.  Any reason why you chose this route?
> 
> Rgds
> Antony