On Tue, 8 Oct 2002, David Graham wrote:
> Date: Tue, 08 Oct 2002 01:01:32 -0600
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: Using CheckLogin tag from within tiles
>
> Craig,
> I agree with most of your points but you must admit that the non-standard
> implementations of CMA are a pain. Not really when you work for a company
> that sells a container (Sun, BEA, IBM) because you'll always be using
> their's, but when developing for a number of containers this can be painful.
>
> It would help if at least one standard implementation was prescribed by the
> spec...I personally like tomcat's jdbc realm implementation.
>
There are actually two pieces to this problem.
* For authorization (i.e. looking up roles), the APIs for
common plugins for containers were standardized in JSR-115,
which is part of J2EE 1.4 (and is being implemented in
Tomcat 5).
* For authentication (i.e. username/password type checks),
no such standardization has yet taken place.
The problem with something like Tomcat's Realms is that they don't come
anywhere close to meeting all the real world requirements (which is
another reason people don't use CMA even if they don't have to worry about
cross-container issues). It is a very complex problem space -- go get and
read the JSR-115 spec (currently in proposed final draft) if you want a
feel for this :-).
I just wanted to remind people that they really are playing with fire when
they take authentication and authorization upon themselves.
> Dave
Craig
>
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> ><[EMAIL PROTECTED]>
> >Subject: RE: Using CheckLogin tag from within tiles
> >Date: Mon, 7 Oct 2002 23:48:38 -0700 (PDT)
> >
> >
> >
> >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]>
>
>
>
>
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
