struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: Using CheckLogin tag from within tiles
Date Tue, 08 Oct 2002 07:15:29 GMT
There is a small complication in that the users and roles often need to be
configurable from within the application by a user using the applications

ie: the users and roles (or to be more
precise:"role-group-like-things-wot-users-have") arent fixed and can be
changed during runtime. - The persistance of this info being handled by the
business layer rather than in the webApp - which doesnt have access to the
underlying database tables either.

Whats the 'best practice' for handling this sort of requirement (which I
imagine comes up a lot)?

-----Original Message-----
From: Craig R. McClanahan []
Sent: Tuesday, October 08, 2002 14:49
To: Struts Users Mailing List;
Subject: RE: Using CheckLogin tag from within tiles

On Tue, 8 Oct 2002, Andrew Hill wrote:

> My (exceedingly limited) understanding of CMA was that it was very
> specific. If so what approach do you recomend for an app (accessing ejbs)
> which customers are to run in their own container, where at development
> one desnt know which container will be used?

To answer this question, you really need to think about what portion of
the problem is container-specific and what is not.  In the case of CMA,
the mechanism you use to set up users/groups/roles is container-specific,
but the application that you deploy is ***not*** container-specific.  Do
you see the difference?

All you need to do is configure users with the correct roles in both your
development environment and your production environment, and your app can
be appropriately tested, and then deployed with no changes to the WAR or
EAR itself.  That is because a WAR or EAR contains zero references to any
actual users - it only talks about roles and restrictions based on those
roles.  Authenticating users, and determining which roles they have, is
the container's problem -- not the application's problem.

> Is it better to ditch CMA and hope for the best from a home grown
> or to try and find the resources to write seperate versions of the app for
> each of the major containers?

Any application developer who thinks that he or she understands enough
about security (and all the possible things that can go wrong) to
implement application managed security safely is welcome to do so.  But
please warn me which publicly visible apps you've built, and I will make a
note not to use them.

I'm very serious about this.

If you don't have a fundamentally correct security implementation as an
overall top level goal (perfect security does not exist; it's all a matter
of how much you're willing to spend versus the risk/cost of security
breaches), you are wasting your time even bothering with it at all, unless
this is a trivially simple intranet app with no damaging implications if
your security scheme is bypassed by enterprising (or malicious) users.

> (Or tell em they can have any container so long as its Tomcat? (This would
> be my choice if I was dictator for life ;->))

Having been a Tomcat developer, I can tell you that even container managed
security cannot be trusted totally (despite how many hundreds of thousands
of times Tomcat has been downloaded, a long standing security
vulnerability was recently found (not with CMA in this case, but the
principle still applies).

But I will trust the container managed security implementation of any
widely deployed container a *lot* more than I will trust the application
managed security of any arbitrary application (including my own).  It is
very much worth the pain of having to be container-specific about
administering your user database to have some comfort in the fact that
better heads than yours has been involved in setting up your container's
authentication and authorization implementations.

You know the number one security-related question on TOMCAT-USER?  "How
can I authenicate my users using Windows security?"  Nobody even seems to
think about the security implications of sending usernames and passwords
across a network where people who are salivating to attack your server can
see it ...


Craig (who subscribes to various security lists and is
       *astounded/scared to death* at how many vulnerabilities
        continue to show up)

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message