Hi again,
I've trimmed the post a little so it doesn't get too long. My comments
are intermixed.
"Danny.Coward" wrote:
...
>
> > 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.
Exactly, 'runtime bindings' are exactly what I'm looking for. I think
they would give the right amount of flexibility and protability that is
needed.
...
> > .- 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.
Ummm. What I want is to be able to define the binding in runtime and in
a web server independent way. If an application doesn't need this to be
dynamic, they should be able to specify it through the deployment
descriptor(pretty much as the actual spec does, just adding some
granularity), but if I need something dynamic in a application, I would
like it to be specified as well. So the binding wouldn't be forced to
ocurr at deployment time. One buzzword that I liked in the JSP spec that
I think it could be applied here is "contract". So I would like the spec
to define the contract between a container/web server and an
application/war file so my security arhictecture is portable between all
this servers.
> 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.
Eummm, I was not talking about pulling the parameters the servlet
expects into the dd. This could be a way to handle it, but I'd rather
use(and it's actually what I'm using) interfaces. So if a servlet wants
to specify in runtime which are the security settings required to
perform a request, it must implement the interface:
public interface SecuredServlet
{
// Used by the container to ask the servlet which role is needed
// to execute the given request on this servlet
public Role getRequiredRole(ServletRequest request);
// Used by the container to ask the servlet which Permission is needed
// to execute the given request on this servlet
public Permission getRequiredPermission(ServletRequest request);
}
It gets more complicated but that's the basic idea. The container then
would use this information, the identity of the actual user that is
logged in, and the user-role mapping to decide whether the user is
allowed to perform the request or not. This way you can specify
everything inside your application and nothing is proprietary so it's
easily portable.
> 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 ?
"Interested" is quite a polite word ;). I'm pretty sure I'm not the
first developer to get tired of writing the security routines over and
over again, or use a proprietary library so I don't get it also. It's
kind of a vicious circle, spec writers complain they don't get much
feedback and people complain spec writters don't listen to them. I'm
glad that at least you took the time to read my mail, as I took the time
to read the spec ;).
>
> > 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.
No, No, the users don't have to exist on the web server. In the WAR you
specify HOW and FROM WHERE to get them in a way that is understood by
all compliant containers. In our applications we have already used a
XML/File based security architecture and a DB dynamic one, I have
already tried the application in 3 different containers and I've had to
change no single line of code to do so, just path settings and the like
which should be solved when using WAR files.
> 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.
I don't know if I get what you mean. But I'm not asking for a tool to
the the role-user mapping that works in every web server. I'm asking for
the specification to make this tool unnecessary. Zero redeployment.
...
> Great - I'll take a look at Orion with this in mind....
> - Danny
In the Orion documentation(quite scarce BTW), check the Orion API,
that's where you can see what they use to define users in an independent
way (they provide EJB and a DB one). But I haven't seen a way of doing
the same with roles and permissions or to specify the permissions
required for a request dynamically. These are, among others, the reasons
why I didn't use it and cooked our own solution. But I loved to see
somebody else had recognized the problem and had done something to solve
it.
If you are interested I can also send you the details of what we've
done, I can even give you some URLs so you can see our application and
check the results of what I mean. But as this would take a couple of
long emails and given the interest that the topic seems to rise in the
list, we might as well follow the thread in private.
Thanks again for your interest,
regards,
Dan
===========================================================================
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
