Hi Daniel,
interesting post - had a few comments for ya...
> Hi,
>
> As Java developer that has been writing server-side (java and non-java)
> applications for a couple of years, I'd like to rise again what I think
> it's a important need. So, following the JSR syntax
>
> 2.2 Need of the Java Community that this work addresses
> Areas:
> 2.2.1.- Better support for the specification of the security
> requirements of an application. This would include a dynamic way of
> specifying the security level(role) required to execute a piece of
> functionality(a servlet/JSP page). That way, the security level could be
> specified depending on the parameters sent in the request, the origin of
> the request, current status of the server... which would allow
> applications to be flexible enough to cover, in a standard way, almost
> any possible security schemes. Servlet containers should then be able to
> use this information to restric access to the application without
> requiring the user to mix security and bussines logic.
> 2.2.2.- Better support for a standard way of specifying the security
> model of an application. This would consist in a standard and flexible
> way of specifying dynamically, or at initialization, users, roles and
> permissions that form the security model of the application. This would
> allow servlet containers to combine this information with the one
> provided in 2.2.1 and restrict, dynamically and effectively, access to
> the various parts of an application.
What is specified in Servlet 2.2 is a way of specifying more or less this role
based security model at deployment time. The authentication model is (more or
less) a matrix of abstract roles vs collections in the URL-space of the web
application. Its expected that different implementations will map abstract roles
to sets of users or user groups on any particular platform, and may or may not
allow administrators to modify this model at runtime.
The granularity of the model is not as fine as you are talking about here. Do
you have a particular scenario where you want to define permissions on a servlet
or JSP based on the path info ?
> 2.3 Explanation of why the need isn't met by existing specifications
>
> Exisiting specifications(namely jsdk2.1 and JSP1.1) don't specify a
> complete and standard way of providing the information required in
> points 2.2.1 and 2.2.2.
I think what the current specs don't address is the level of granularity in the
model that is there that you are talking about. In general, the last revisions
of the spec standardized some of the deployment issues of JSPs and Servlets. We
had not yet encroached into the territory of the administrator, and had left
many of those functions up to vendors.
As far as 'standard' goes - there are many 'standard' ways of defining such a
security model... :-)
Current specifications allow defining security
> constraints through the deployment descriptor, which must be rewritten
> everytime a security constraint changes.
Well, you could implement it this way by rewriting the dd, but its not
necessary. The deployment descriptor describes the contract between the deployer
and the container at deployment time. It doesn't say anything about maintaining
any particular formats once the application is running.
And it doesn't specify a
> standard way of defining completely the security model(point 2.2.2)
> which will surely lead to the development of non-portable
> vendor-specific solutions by server and tool vendors.
Not currently at the granularity you are talking about, no.
That translates in
> non-easily-portable applications because the security part has to be
> re-deployed every time the application has to be ported to a different
> server, and not flexible enough applications as every time the security
> constraints change, the application needs to be redeployed.
If all the vendors find the current model inadequate then yes they'll all do
vendor specific things to augment it. But for compliance with the spec, they
should support the model in the spec, even if they augment it; so this shouldn't
break portability.
Thanks for the post - do you have a particular implementation in mind when you
make these comments ? If so, which one ?
- Danny
> -------------------------------------------
> Daniel Lopez Janariz ([EMAIL PROTECTED])
> Web Services
> Computer Center
> Balearic Islands University
> -------------------------------------------
Danny Coward
Servlet Specification & Web Java
Java Software Group, Sun Microsystems
[EMAIL PROTECTED]
===========================================================================
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
