Hi,
My name is Dan Kaschner and I am new to this list. My question has to do
with finding a method to direct a servlet engine to reqeuire new servlets
to:
a) Only allow subclasses of a specified class
or
b) Force servlet requests to got through a specified servlet.
>> WARNING: the following discussion gets somewhat lengthy, proceed at
your own peril :-)
The reason I am looking at these mechanisms is that I am working on an
enterprise security infrastructure. It will use the Java Authentication and
Authorization Service (JAAS) and we want a way to "force" authentication /
authorization for any http access to our site. The above scenarios are
proposed as two design alternatives to achieve this goal. Either way we
should be able to check the associated http session and check for a cached
"subject" object which will hold all allowed service authorizations (if they
authenticate). The "securedServlet" will be able to handle attempts at
authentication via a client certificate (using SSL 3.0 protocol) and if that
doesn't work any additional mechanisms we allow (userid / password, etc...),
log failed attemtps, etc... I am aslo hoping to "imply" servlet actions
based on a subject's group / role, ie., the ability to service a doGet(),
doPut(), doPost(), doDelete(), doTrace(), etc..., and log all bogus access
attempts...
Ultimately we do not want the applications programmer to have to worry about
authentication / authorization, but just "use" security features to easily
determine assigned permissions. The above two scenarios have been proposed
as a means to enable this ability. Without the ability to force either of
these, I feel that we cannot adequately enforce a security policy (at the
servlet interface) short of relying on local development "conventions",
which as we all know are fallible.
Lastly, I owuld hope to be able to acomplish this in a "portable" manner, as
we have currently use at least two servlet engines at this point in time,
and we would like this solution to be independent (as much as possible) from
the platform.
Any way, for those of you still with me... sorry for going on so long, and
thanks for taking the time to read this far :-)... I look forward to
hearing your opinions, experiences and potential solutions in this area, in
additon to getting acqaited to the discussion community on this mailing
list.
Thanks again,
Daniel Kaschner
Systems Architect
eBenx
605 North Hwy. 169
Suite LL
Minneapolis, MN 55441-6465
(763) 614-2211
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
