|
From: Isabelle M. <isa...@me...> - 2003-05-26 08:45:55
|
Hi Juergen, I have found container authorization to be pretty useless. In a typical business scenario, the user population is fluid (add, delete, ...) and constantly changing the xml files is a no-no. On the other hand, there are also lots of different ways people solve the problem in their applications : database, LDAP, ... Maybe JAAS support would be nice, then it's simply a question of having the service providers for the different protocols. Isabelle On Sun, May 25, 2003 at 11:31:55PM +0200, jürgen höller [werk3AT] wrote: > Hi everyone, > > I just had a look at J2EE 1.4's JACC (Java Authorization Contract for Containers), and I'm disappointed. Well, it deals with authorization of web and EJB resources, what else would you expect from that name? But who needs that, deployment descriptors allow to specify resource authorization in a good enough way already, e.g. in web.xml. > > What I really miss is portable authentication. Every freaking container has its own API for authenticators, basically taking username and password, and returning the roles for this user, if any. Of course, there are always default implementations for XML files and database tables. But you'll have to get container-specific to use the J2EE login infrastructure in your apps if you keep the user data in your application database, or some other application-specific datastore. > > Furthermore, a J2EE web login simply authenticates and returns to the original URL if the user is authorized. On each following URL, the authorization check happens again, forbidding access if the user isn't in an appropriate role. Of course, servlets can programmatically access the user name, and check if the current user is a given role - but that's it. There are no hooks for loading user-specific settings on login, for example. > > Thus, J2EE authentication seems only usable for basic website administration purposes, like restricting certain namespaces for administrators only, specifying the administrator usernames and passwords in a server-specific way. It's completely inappropriate for handling a tightly integrated application user base, potentially with thousands of customized users. > > Why? The J2EE model doesn't really fit the concept of a login into a rich web application. Typically, a login page is either the starting point, or required for some parts of the application. On login, user settings get loaded and put in the session. Web controllers offen act according to these user settings, or are forbidden without login. A logout either removes the user settings from the session, their existence being related to the login status, or invalidates the session. > > All things considered, it would make sense to offer authentication support within Spring's web MVC. The basic requirements are the ones from the last paragraph. Of course, it is already possible to implement this via a custom LoginController, checking a login/logout request and handling the user settings in the session, and respective checks in business controllers. I just wonder if we could offer dedicated authentication support to ease the task. > > Regards, > Juergen -- Isabelle Muszynski Software Engineer Zandweellaan 4 2660 Antwerpen Belgium Tel. 32-(0)3-830 18 54 Mobile: 32-(0)485 49 50 89 Email: isa...@me... Website: www.meta-logix.com |