> First of all, thanks for your comments. And now my coments from Dani(the
> spanish way to write it) to Danny ;) :
There are a lot of us around...:)
> 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.
Aha. I see what you are looking for. Its certainly an interesting route to do
this. This task of standardizing not only the deployment information - which
describes the environment needed by the code, but of the 'runtime bindings'
which describes the information needed to bind an application into a
particular operational environment I believe is being looked at in another JSR
(proposed by someone at NASA) which is attempting to define a deployment API.
The JSR is phrased in terms of J2EE, so would also apply here.
> > 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.
> .- 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?
Right - I guess one conceptual change this would involve would be the binding
of deployment information like web resource collections to actual user names
or user group names on a particular web server.
As far as the granularity of the security model goes, then it would make sense
in your scenario to make the model more fine grained and it would certainly
seem feasible so to do. The parameters a servlet expects are 'known' to the
developer (else he wouldn't look for them in his code) so could be pulled out
into the dd.
I'm actually very interested that we haven't had a whole lot of feedback on
the security model that is specified in this latest version. I wonder if
people find it adequate, or have just not yet had time to digest (excuse the
pun) it ?
> 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!
Well, if the rolemapping->user table was specified inside the WAR it probably
wouldn't be portable unless the same users existed on all web servers. But I
do see the need to be able to specify this in a standard way.
We do have a section in the JSR that covers tool support. That would seem a
sensible place to take a look at the role-> user mapping issue.
>
> 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.
Great - I'll take a look at Orion with this in mind....
- Danny
===========================================================================
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
