On Mon, 8 Jul 2002, J�rgen Weber wrote:
> Date: Mon, 08 Jul 2002 17:48:29 +0200
> From: J�rgen Weber <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: container managed security
>
>
>
> Hello,
>
> I am into evaluating Struts.
>
> The struts-example.war does authentication for its users programmatically.
>
> Why doesn't it use container managed security?
>
The example app rolls its own for one and only one reason -- one of the
purposes of this webapp is to detect whether you have Struts installed and
working on your container correctly. The less configuration tinkering you
have to do for a "hello, world" application to work, the better.
In general, I believe that apps should use container managed security
rather than rolling their own.
> Wouldn't it be simpler (not having to reenvent the wheel), safer (the
> container will do it better)
> and standards compliant (servlet specification chap. 12) ?
> Especially for enterprise applications that often use LDAP to authenticate
> users
> container managed security is very powerful if an application server
> supports an LDAP realm.
>
> Instead the Newbie FAQ (http://jakarta.apache.org/struts/newbie.html) links
> to
> (http://www.mail-archive.com/[email protected]/msg24504.html)
> three other ways,
> that do not use the standard features of the container.
>
> The downpart of container managed security mentioned in
> [htttp://www.jguru.com/faq/view.jsp?EID=471952]
>
> "The only downside to this approach is that there is not yet a standardized
> API for portably accessing and maintaining a "database" of users and roles
> ("database" is in quotes because the actual implementation could be
> anything, including static text files or directory servers)."
>
> is not a downside, because security is a sub-modul of the container and does
> not have/need a standard API to the web application.
>
This is *definitely* a downside for application portability in some
circumstances.
Consider that you are writing a portal application, with the usual self
registration facilities. It is trivially simple to make the portal app
itself portable across containers, if you just stick to standard servlet
and JSP facilities. But the notion of "add a new user" is not portable,
and requires integration with each container's own user database update
mechanisms (for example, using a particular Realm in Tomcat). There is no
way to write the functionality for this in a portable way.
That being said, I think it's still worth the extra effort to build such
integration links for the app servers you care about. Quite often, that
will simply be a matter of updating whatever database or directory server
your app server is talking to, and not require any deep API-level
connections. But this is still a hindrance to the usual write-once
run-anywhere feature normally associated with webapps.
> Thank you,
> Juergen
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
