|
From: Rod J. <rod...@in...> - 2003-05-27 09:22:11
|
I agree, maybe Spring should offer this.
Spring's ancestor, the MVC framework I wrote for FT group, did
authentication and it worked well.
What about adding an authentication interceptor? I think authentication is
arguable orthogonal to the app proper, hence a good candidate for AOP. As
all controllers implement an interface, we can easily put a global
interceptor in front of all of them.
I agree: standard J2EE authentication is not really standard, and just
doesn't cut the mustard for most real apps.
This is not something we should consider for 0.8, though!
Regards,
Rod
----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, May 25, 2003 10:31 PM
Subject: [Springframework-developer] Authentication and authorization
> 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
> NHun~ujʉjjjjvv
> 9r>JF yqj~{zzym +-.ʭǟ+-떳b ~즸 (G^쮽h
|