"Bailey, Jeff A" wrote:
> I asked:
> > >More specifically, I want to be able to define security constraints using
> > > the url-pattern matching techniques in the web.xml portion of my .war
> (which
> > > is a portion of my .ear) but use an external application (or servlet or
> > > whatever) to assign users to groups. This would allow great flexibility
> > > when it comes to defining which directories, files, servlets, etc are
> > > protected from which groups, users, and such. My authentication
> mechanism
> > > performs authentication against our network servers as assigns
> individuals
> > > to groups based on criteria which has been defined by management
>
> Craig Responded:
>
> > The mechanisms by which you do this will be specific to each
> > container, because
> > there's no standard API. For example, in Tomcat 3.1 you have
> > to extend an existing
> > class (that does the authentication checks) to interact with
> > your underlying source
> > of authentication information instead of its default one.
>
> And now I ask:
>
> So, in this case, would I still define the HTTP authentication type as being
> "FORM" in the web.xml?
You can use whichever authentication method your container supports (of the four
standard options: BASIC, DIGEST, FORM, or CLIENT-CERT).
> I am a bit unclear of this. My thoughts are that my
> module would actually replace the method which authenticates based off
> information in the principals.xml or would this method work in conjunction
> with principals.xml (so that if i use FORM authentication it uses my custom
> module but BASIC would refer to principals.xml)? Is this corret. I am more
> interested in replacing the use of principals.xml simply because of the
> volume of accounts I am dealing with. Would / could this be application
> scope (instead of server scope)?
>
For Tomcat 3.1, you would be replacing the standard SecurityCheck interceptor
(that looks in conf/tomcat-users.xml) with one that looks up in your database or
directory server or whatever. This can be replaced on an
application-by-application basis.
The way to think about it is this -- you don't want to change the mechanics of
how, say, BASIC authentication works (sending back the "not authorized"
challenge). What you are asking about is replacing the logic that Tomcat uses to
look up the username and password that the user submits.
>
> I am a bit confused but think I get the general idea. We actually are
> currently using Orion and Resin (mostly just for testing my applications
> across other servers) and if I understand how this works on Tomcat, I can
> begin discussing the feasibility of doing this sort of operation on Orion
> and / or Resin.
>
You'll have to talk with those developers about how to integrate with them --
there's absolutely no guarantees of consistency in approach.
>
> Is there any documentation on doing this sort of thing? Has anyone done it
> that you are aware of?
>
There were some comments in the TOMCAT-USER or TOMCAT-DEV mailing list archives
over the last few weeks from Mark Wilcox, who implemented user lookups in a
directory server via JNDI using Tomcat. I would not know of any such experiences
with other containers.
>
> -jeff
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
