On Tue, 8 Oct 2002, Andrew Hill wrote:
>
> My (exceedingly limited) understanding of CMA was that it was very container
> 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 time
> 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 solution,
> 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 ...
Sheesh.
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
