Ian wrote:
> Craig:
>
> I just read the Servlet 2.2 spec on security and container-based
> authentication. Thanks for pointing it out to me.
>
> It seems to me that the new spec has added 2 things:
>
> 1. the 'boolean HttpServletRequest.isUserInRole(String role) API
> 2. a declarative way to specify URL Resource/HTTP GET-POST/Role restrictions
> in the servlet engine XML properties.
>
There's at least one more addition relative to security --
HttpServletRequest.getUserPrincipal() returns a java.security.Principal object
representing the currently authenticated user.
>
> However, to use this in a real application, we would still need a
> programmatic API for adding new user/password/role data from a servlet
> (hopefully using an API that is standard/portable across servlet engines).
> Does this exist somewher else in the J2EE spec?
>
Short answer: there is no current Java API (even in the J2EE spec) for adding new
users and/or administering roles.
IMHO, such an API may or may not be desireable (see some of the considerations
below), but the concept is still usable without this part being portable.
Consider the fact that a very large number of environments have existing
mechanisms to create new users and assign application capabilities for their
environments. Examples are the Unix /etc/passwd and /etc/group files, directory
servers accessed via PAM modules, the NT user registry, and similar capabilities
on mainframe systems.
Without the 2.2 enhancements, the only way for servlet based apps to interact with
these mechanisms was to write the appropriate "login" logic into your apps
themselves. However, when you do so, you probably don't bother to add "user
create" type functions -- the underlying security realm already has tools for this
purpose, so there's no need to duplicate them.
For the 2.2 API, what you really want is a way to connect your servlet container
to this security realm. At the moment, that's going to be a per-container issue,
but remember -- this only affects deployment of the servlet container itself,
*not* the applications you run in it.
As an example of this, I am at the moment adding support for the 2.2 API security
requirements to the Jakarta Tomcat servlet engine (http://jakarta.apache.org) --
you can see the progress to date in the source code accessible via CVS. The plan
is to introduce a pluggable component architecture that lets you "connect"
Tomcat's security checking to *any* underlying security realm that you already
have. If you don't have one, a couple simple connectors based on stand-alone
files (reminiscent of htpasswd files used in Apache, but stored in XML format
instead) or JDBC access to simple database tables, will be included.
At the moment, this API will be specific to Tomcat. Other 2.2 containers will
provide their own mechanisms. For instance, an application server (like the J2EE
reference implementation) will provide connectors to the security realm already
supported by the rest of that application server. But the key point is that this
is a one-time issue when you deploy the container -- it is *transparent* to the
applications you run inside that container.
Should this API be standardized? Perhaps, but it's going to be quite a challenge
to encompass all of the nuances of legacy security realms in a single generalized
API. This might be an area better left non-standardized, to avoid stifling
functionality needed for particular application requirements -- particularly when,
in many cases, the legacy functionality already exists and is in use. If the
general API did not include some particular functionality that was needed, this
would be a strong disincentive to using Java servlet technology for that app, and
that would be a shame.
>
> Thanks again,
>
> Ian
>
Craig McClanahan
>
> ----- Original Message -----
> From: Craig R. McClanahan <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, November 28, 1999 5:32 PM
> Subject: Re: Looking for a java.security.acl database implementation...
>
> > Ian wrote:
> >
> > > Hi all:
> > >
> > > Does anyone know of a freely available implementation of the
> > > java.security.acl interfaces that uses JDBC against access control
> > > information stored in a relational database?
> > >
> > > I want to use these standard, open interfaces for my JSP/servlet app
> > > infrastructure controlling users, groups and their resource permissions.
> > > Many people must have implemented these already for their servlet
> systems.
> > > Have any been made publicly available?
> > >
> >
> > I don't know of any generally useful implementation of these interfaces,
> but I
> > have a suggestion for some additional research for you
> >
> > Version 2.2 of the servlet API includes the ability to define
> "declarative"
> > security, based on the concepts of Principals and role names. The exact
> same
> > security architecture is defined in EJB 1.1, so it will likely be common
> to
> > delegate responsibilities for this stuff to your application server
> containers
> > (once these standards are implemented) versus coding support for the ACL
> > interfaces directly in your applications.
> >
> > GIven that servers implementing these new APIs will be available fairly
> soon, you
> > might want to think about how much effort to invest administering security
> > yourself (via the ACL APIs or other such mechanisms) versus container
> managed
> > security.
> >
> > For more information, see the specifications for servlet 2.2 and EJB 1.1,
> > available at the JavaSoft web site. The "Application Programming Model"
> document
> > on the Java2 Enterprise Edition (J2EE) site also has some useful
> discussions of
> > security mechanisms using these new approaches.
> >
> > http://java.sun.com/j2ee
> >
> >
> > >
> > > Thanks,
> > >
> > > Ian
> > >
> >
> > Craig McClanahan
> >
> >
> ===========================================================================
> > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> > FAQs on JSP can be found at:
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> FAQs on JSP can be found at:
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
