Hi Danny,
First of all, thanks for your comments. And now my coments from Dani(the
spanish way to write it) to Danny ;) :
Danny Coward wrote:
>
> 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.
I understand how this would work. My point here is that DIFFERENT
implementations will map abstract roles and sets of users to...
DIFFERENTLY. That means that if I have my web-app deployed in Tomcat and
I need more power and decide to buy WebLogic, Orion, whatever... I'll
need to learn the way the new containers maps roles with the users and
"re-deploy" the security part. I agree this shouldn't happen very
often, and in some cases it shouldn't take too much time but I think it
shouldn't be necessary and the spec could help solving it.
> 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 ?
Yes, I've written lately two completely different Java 100% applications
and in both cases I had the same servlets/Jsp accessed by different
users with different permissions. I explain:
.- Servlet (or JSP page) A. shows info about a users, the identifier of
the user is sent as a parameter or (as I did in my last project) is used
as virtual directory in the path.
.- Each user should be able to see only it's own information so what I
do is give each of them a different Role, and I decide for each request
the role that is needed by looking at the parameter, or the path.
I guess you might be able to "emulate" this wih isUserInRole() and other
included methods but you would then have to do it in your business logic
code, and what happens is the answer is "no"? Should you answer yourself
a 401 response? I though the whole idea was to let the container handle
this (a very good idea) and let the business programmer write business
logic.
> > 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.
I agree, my first concern is granularity but my other big concern is the
"leave that to the vendors" thing. I agree that the administration part
should be left to them so anybody can charge for the "added-value", but
I'm talking about specifying the whole security architecture in a
standard flexible way. They can add goodies over the standard if they
please, but we should have a minimum standard. Else we are in the same
situation that we all hated with old web server authentication schemes.
An example:
.- Container TotCam is free and allows you to define your user-role
mapping through text files using XML and the TotCam.dtd.
.- Container CotMat is comercial and allows you to define your user-role
mapping through a proprietary DB.
.- Container MacTot is really good and allows you to define your mapping
through RMI so you can get your mappings from wherever you want.
Do you think the security architecture of an application is easily
portable among these containers? So we are back again to the
marry-an-application-to-a-vendor way of doing things. I know it
shouldn't be much of hassle but is it really necessary?
> As far as 'standard' goes - there are many 'standard' ways of defining such a
> security model... :-)
I know, I know :). But a spec shouldn't be "the one and only" way of
doing it. Just an agreement that this is the way that covers almost all
the cases and can be easily ported. Then let the vendors try to get
buyers through their proprietary goodies that are non standard, as long
as thier containers are also compatible with the portable way the spec
dictates.
> 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.
Neither am I. That's also one of the places where vendors could add
their value. I just want the contract to be portable, flexible, and
fully specified. I wouldn't get into telling the vendors what they need
to do in runtime ;).
> 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.
IMHO, it does because the model spec doesn't specify it all. For me
portable would mean move the war file from one container to another
and... alehop!
> Thanks for the post - do you have a particular implementation in mind when you
> make these comments ? If so, which one ?
Thanks again for your answer, sometimes it seems nobody reads my long
postings ;). Talking about an implementation... Our own ;). Our first
applications are running fine(production) since 2 weeks ago using a
framework that implements all that I talked about. If you are interested
I'll gladly explain to you what I've done and I'll let you have a look
at the running application because it's very easy to add a user that can
just look-but-not-touch. Oh, this framework also adds application wide
event handling using the same flexible approach. It's not a commercial
product but if you want to have a look at one, Orion partially
implements a similar approach but I was not completely satisfied with
it and I keep on with my own. But it still is worth having a look at it.
Regards,
Dan
-------------------------------------------
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
