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. Dave >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]>
