Daniel Lopez wrote:
> Hi,
>
> Comments over comments ;), I've cut some pieces of the mail so it
> doesn't grow too much.
>
I will shorten it some more and address just a couple things. Pretty soon there won't
be
anything left ...
> > > 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...
>
I've been involved in the Apache JServ project for just under a year. Examples and
docs
save you a *ton* of questions, but not quite all of them.
> > 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 :).
>
You're right ... the "how" is not standardized. In my mind, that's actually a good
thing
in the context of a generic specification like servlets, because there are so many
varieties of existing authentication and security mechanisms that you might have to map
to. The servlet API developers decided to focus on a couple of very simple "what"
issues
(how do I know which user is logged on? how do I know if they are allowed to
participate
in a particular role?) instead of the "how".
Ideally, my servlet container should allow me to plug my own security realm component
into
their architecture. At the moment, there are basically no API contracts between the
servlet container and the server in which it runs. I wouldn't be surprised to see
movement
towards a "service provider interface" level API that would standardize some these
interfaces, without mandating specific implementations.
On the other hand, you're probably right about JDK 1.3 -- the particular issue of
authentication and access control might actually get standardized at the core language
level instead, and servlet containers can just leverage that.
>
> > 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.
The equivalent to your properties file is the security declarations in the deployment
descriptor itself.
The basic concept is just like with asking your web server to put password protection
on a
particular directory. Doing this is a change in the server configuration, and
requires no
changes to the individual pages that have been protected.
>
>
> > * 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?
>
Yes, I was thinking that sometimes the UI needs to be modified based on access control
issues. A couple more examples:
* You have a customer list page that is visible to both the
"user" and "admin" roles. When accessed by a "user", no
changes are allowed. But, when accessed by an "admin",
the customer name is hyperlinked to an edit screen.
* In a payroll system, a "user" might not be able to display
the salary information, but a "manager" can see it.
IMHO this will tend to be the exception rather than the rule, but it does mean you
don't
have to create two nearly identical pages to deal with the two roles.
>
> > 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.
I think it would be of interest. Not everyone is going to use the container-based
security
model (either they have existing logic to deal with authentication and access control
already, or they prefer to build their own model as you did), so alternative
approaches to
the issues will be quite useful. My desire is that people become aware of the new
container-based security features in 2.2, and how they may (or may not) apply to the
apps
they are developing.
It might pay to monitor the Jakarta based mailing lists (you can sign up at
http://jakarta.apache.org) for when the source code control system (CVS) becomes
available
-- hopefully not very much longer -- and then consider contributing your framework.
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
