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.
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. Current specifications allow defining security
constraints through the deployment descriptor, which must be rewritten
everytime a security constraint changes. 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. 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.
Implementation note: We believe that the proposed architecture could be
acomplished through the use of interfaces that would specify the
contract between the applications and the containers. The applications
could then provide this information to the containers in the standard
way by implementing those interfaces. This interfaces would specify the
minimum funcionality needed to cover the maximum flexibility but
allowing the architecture to be extended to cover very specific needs.
We had implemented such an architecture for our applications and we are
very satisfied with the level of flexibility, as opposed to having to
redeploy the application every time a change is made in the security
constraints.
Regards,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
===========================================================================
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
