I've interspersed a few comments and notes in the discussion below.
Daniel Lopez wrote:
> Hi,
>
> I always have to remember to hit reply all instead of reply so I'm with
> you on this one, Craig ;). I also agree with Brian, I find most of your
> posts to be very useful and clear so thanks.
> Now back to the point, regarding the topic of restricting access to the
> JSP/servlet applications I follow and approach which works just great
> for our apps. Instead of including a scriplet or piece of code in every
> JSP/servlet that belongs to our application, I developed a little
> flexible framework because I wanted this to be "simple" from the
> developers perspective so let's explain it with a example:
> 1 .- You first divide your logical application into "domains"
> Accessing data from user X can be a domain, from user Y another domain
> Accessing administration and monitoring data can be another domain
> Domains must be independent (they can't cross each other's boundaries)
Does this correspond in your mind to the boundaries of a web application (i.e. a
single servlet context)? That is one of the areas that I am thinking through a lot in
my designs -- when a particular user is allowed to operate more than one "logical"
app, should they all be in the same servlet context or not.
>
> 2 .- Optionally, you might define which operations can be performed on a
> domain
> 3 .- Define the users your application is going to have
> 4 .- Define which users can do which operation on each domain
> 5 .- With that information, you create a class that I call SecurityModel
> extending
> from a basic abstract class that the framework provides.
> 6 .- Then you can create a servlet or a JSP extending from basic classes
> and providing the information necessary for the security framework to
> protect it. That means:
> .- Change the extends of your servlet or use the extends directive in
> your JSP so you extend the basic secured class.
> .- Implement three methods to return:
> Which SecurityModel are you using ( see point 5)
> Which domain does this servlet/JSP belongs to (see point 1)
> Which operation is this servlet executing (see point 2)
> Note: Last two can be decided on runtime depending on the request.
> 7 .- That's all, after that, the security framework will use the
> information you provide with methods defined in point 6 and the
> information you provide with the security model defined in point 5 to
> deny/allow access to your individual JSP/servlets and it's decided in
> runtime so you can have a servlet/JSP that decides which user to allow
> or not, depending on the parameters of the request.
Personally, I have shied away from using the "extends" attribute in JSP pages,
primarily due to the warnings in the JSP spec that you might be "cramping the style"
of the JSP page compiler's ability to create optimized code. This is certainly a
valid use of the concept, however. This model is also quite useful in pure servlet
based frameworks and architectures.
>
> I had an application consisting on a set of around 10 servlets, 20 JSP
> pages and a protected it in 30 minutes, the changes to the code where
> minimum as I used inheritance where the values where the same for all
> JSP/servlets. This servlets/JSP upload/download files, get and update
> data from a database,... I'm quite happy with it and I'm looking forward
> to protecting other applications in our organization.
Cool ... re-use is where the benefits of a good underlying foundation really show up.
>
> At the moment the framework uses http authentication instead of sessions
> to authenticate users, even though we are working on allowing both
> systems but you still can use sessions for other purposes, of course.
>
> I was writing a paper about it as I find it quite interesting and I was
> also planing to ask my boss to allow me to release this thing as
> OpenSource but I wanted first to have some documentation and sample
> applications.
Ah, someone has seen how many questions can get generated very quickly on open source
projects :-).
>
> After reading what Craig said about servlet API 2.2, I wonder if this is
> wasted time or will we be able to merge this new features with our
> framework. I had a look at how EJB spec was approaching security and
> even though it was close, I didn't like the statically specifying
> security in deploy time and letting the server specify how
> users/roles(domains) are specified, I send a suggestion to the spec,
> suggesting runtime and a basic security model could be good but I got no
> answer so...
If you don't like the declarative security stuff in EJB, you're not going to like it
in servlet 2.2 either, because the principles are exactly the same.
However, I don't feel particularly constrained by the declarative model. I plan to
use role-based constraints for most things. You could also consider a role to be a
"group", and particular users can belong to one or more of these groups based on what
they are supposed to be allowed to do. While the application is running, the role
name that protects a portion of the application is static, but which users belong to
that role does not have to be. That mapping is up to whatever security realm your
servlet container is using to link roles to users.
In the JSP pages and servlets of an application using these facilities, the you will
generally see one of the following patterns:
* No mention of security at all -- because the container
does all the protection for you. (You do need to declare
a login form page and an error page, though).
* Simple conditionals if you are showing the same page
to users with different roles. For example, you might
add some additional menu options if the current user
is in the "manager" role as well as the "user" role.
When the JSWDK source code is contributed to the Jakarta project
(http://jakarta.apache.org), one of the first places I want to focus my contributions
on is building a mechanism so that you can connect a JSWDK-hosted application to one
or more security realm implementations, based on a variety of technologies (flat files
like htpasswd in Apache, JDBC-accessed databases, JNDI-accessed directory servers, and
so on). Having this, coupled with an example application to create and modify the
legal users and roles (JSP+servlet based, of course :-) will give people a powerful
mechanism to take advantage of the declarative security capabilities.
Craig
===========================================================================
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
