Hi,
Comments over comments ;), I've cut some pieces of the mail so it
doesn't grow too much.
"Craig R. McClanahan" wrote:
>
> I've interspersed a few comments and notes in the discussion below.
>
> Daniel Lopez wrote:
>
> > Hi,
> >
> > 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.
Well, we also thought quite a long time about this one. The overall idea
of the system is that if you want your user to access different
applications without having to type the password again, then consider
the apps like different domains inside the same security model, thus
sharing the same "servlet context". If you want the same users to access
too diferent applications and "separate" access to them, use the same
data but create another security model for this, and you can even use
the same security model but separate two applications, because you can
specify create another "security handler"(we call it Sentinel) instance
and thus having two different security contexts. The sentence "Domains
must be independent" means that a servlet/JSP can just belong ONE domain
in a specific moment(each request actually) but it cannot belong to more
than one at the same time.
>
> >
> > 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.
Yeah, we also thought a lot about this topic. The problem is that if you
don't use the "extends" feature then you have to force the final
developer to add some code to his servlet/JSP and I wanted the system to
be as simple as posible. I felt the same shiver when I read the JSP spec
but it's been working so fine and fitted so well with servlets as well,
that I decided to use it :). I haven't really looked into it it but
Dynamic proxies, that will come with 1.3(JDK2), might help with it.
> > 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.
Next big step will be creating a remote secure service to monitor "a"
security framework so you sould be able to control the security of all
the applications that use this library from a single point. Another
thing in the "to do" list :).
> > 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 :-).
Well, I have no experience in working with open source projects, yet.
But I've used quite a lot of them and I'm one of this users that love to
have manuals and samples so...
> >
> > 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.
Agreed. In our framework roles=domains, and you even have finer grained
control as you can specify operations for each role, even though it's
not mandatory.
> 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.
Well, the thing that bothers me is that "how" this mapping can be
specified is not "standardized" so changing containers might mean
re-creating it, as usually happens with web servers authentication. In
our framework this mapping is specified by extending a class called
SecurityModel (what a coincidence, huh?). So changing your container
means nothing, I had to change it three times and no single change
involved :).
> 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).
ummm, you could specify all of this in a propertis file and load it in
the security manager at init time. You'd lose some nice runtime features
but...
I already have properties for any kind of access error you can get,
wrong password, user doesn't exist, time out expired, all can be
configured at deploy time and no recompilation involved.
> * 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.
I don't get this point, this sounds like presentation logic but... mixed
with security? I provide the user that has been autheticated to the
"secured" JSP/servlet so he might use this value to modify its UI. Was
that what you meant?
> 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.
Well, that's exactly what we tried to do with our framework, as long as
you extend the SecurityModel base class, you can get the security
information from where you want. We started the first tests with a flat
files basic model and now it's a database, again no single line of code
changed in the application. You just have to provide another
SecurityModel. If you are interested, it would be a pleasure for me to
discuss more throughly about this, I don't know if this framework could
be a good contribution, I'm sure it would need some fixes, but we might
try to get something good from it. I could try to bundle a small demo
and send it to you, if you are interested, so you could get a better
perspective.
Thanks again for your insight,
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
