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 UI.
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 [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 08, 2002 14:49 To: Struts Users Mailing List; [EMAIL PROTECTED] 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 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
