Actually, the interface is dictated by the Servlet API. We need to secure
the HttpServlet class, which of course, implements (indirectly) the Servlet
interface that all servlet engines rely on. One option is to subclass
HttpServlet into a SecuredServlet class and finalize the service() and
doXXX() methods. Allowing the security layer to implement the authorization
and authentication. Application-specific behavior would be housed in
protected methods like doService() which would only be called from the
SecuredServlet.service()if an authenticated Subject can be attained...
If we can authenticate and authorize a Subject instance would be cached in
the associated HttpSession, making it available to the application
programming layer. Application-specific methods are only called if the
postcondition is satisfied... i.e., Subject is cached in the session.
Otherwise the security layer will reject the request... Obviously this is
the simplified version.
Key to this alternative is the ability to require all "application" servlets
deployed on this servlet engine to be derived from the SecuredServlet...
otherwise a developer could, mistakenly (or malicioulsy), derive from
HttpServlet and deploy code outside the secured environment.
I do not know if it is possible to instruct the engine to limit deployed
instances of application servlets to a subclass of the SecuredServlet... if
not, the system can be relatively easily circumvented.
-----Original Message-----
From: Tom K. [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 21, 2000 8:59 AM
To: [EMAIL PROTECTED]
Subject: Re: Servlet subclassing
I may be going out on a limb here, but I would think that using an interface
with its members declared private would force users to implement what I
think you are trying to do. Another way may be to just build a regular class
and use private members. You may have to obfusticate your class to keep
someone from decompiling it.
Tom Kochanowicz
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
Kaschner, Dan
Sent: Friday, July 21, 2000 8:18 AM
To: [EMAIL PROTECTED]
Subject: Servlet subclassing
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
___________________________________________________________________________
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
___________________________________________________________________________
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
