On Tue, 8 Oct 2002, Andrew Hill wrote:
> Date: Tue, 8 Oct 2002 15:15:29 +0800
> From: Andrew Hill <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Using CheckLogin tag from within tiles
>
> 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)?
>
I would tend to create a DAO interface for these requirements (just like
anything else), and then build an implementation that interfaces with the
container-specific features for each container I supported. That way, you
can isolate the container dependencies into a very small adapter layer.
Craig
> -----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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
