RE : [Springframework-developer] Authentication and authorization

[JP P. <jp....@ti...>]

Hi Isabelle, J=FCrgen,

XML has nothing to do with container authorization. It is only the
default setting of most application servers. I have only worked with
Tomcat and JBoss, but both allow the use of LDAP or database as
authorization repositories (JdbcRealm for Tomcat). Changing xml files is
not a job in this case.

I can't let say that it is useless. But, as said J=FCrgen, it doesn't =
make
the complete job. J=FCrgen omitted the possibility to have conditional
parts in JSP depending of the status logged/not logged or having a given
role. The management of protected pages is clean and simple.

Nevertheless:

- The login page cannot be asked directly. I had to create a dummy
protected page to simulate a login. The page simply redirects to the
home page.
- As consequence, it is not possible to have form fields for login in
the banner or other continuously displayed part of the page.
- The login process doesn't let loading a custom object in the user's
session ( no hooks). I had for every request to check elsewhere (top of
servlet, filter, ...) if the user is already logged in without having
his context loaded and make the job if necessary.
- The setting of the repository management is server dependent.

The need of a general authentication management in the framework seems
to be clear as no standard solution answer to the developer needs. The
main question is has this to work in part with the container
authentication or not (maybe optionally). If yes, and it would have an
interest, the main issue is the last point I mentioned, the
server-dependent nature of the authentication repository settings. The
part included in web.xml is, in contrast, portable.

Regards,
Jean-Pierre

> -----Message d'origine-----
> De=A0: spr...@li...
> [mailto:spr...@li...] De la
part
> de Isabelle Muszynski
> Envoy=E9=A0: lundi 26 mai 2003 10:46
> =C0=A0: j=FCrgen h=F6ller [werk3AT]
> Cc=A0: spr...@li...
> Objet=A0: Re: [Springframework-developer] Authentication and
authorization
>=20
> Hi Juergen,
>=20
> 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.
>=20
> Isabelle
>=20
> On Sun, May 25, 2003 at 11:31:55PM +0200, j=FCrgen h=F6ller [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
>=20
> --
> 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
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer