container managed security

[Jürgen Weber <we...@hotmail.com>]

Hello,

I am into evaluating Struts.

The struts-example.war does authentication for its users programmatically.

Why doesn't it use container managed security?

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/struts-user@jakarta.apache.org/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.

Thank you,
Juergen


_________________________________________________________________
Testen Sie MSN Messenger für Ihren Online-Chat mit Freunden: 
http://messenger.msn.de


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: container managed security

[Joe Germuska <Jo...@Germuska.com>]

At 5:48 PM +0200 2002/07/08, Jürgen Weber wrote:
>Hello,
>
>I am into evaluating Struts.
>
>The struts-example.war does authentication for its users programmatically.
>
>Why doesn't it use container managed security?

I would assume simply because that's easier for an example.  There's 
nothing preventing anyone from using container managed security for 
Struts.

Do you see ways in which the Struts framework can do anything useful 
to make it easier to implement container managed security?  I can 
imagine perhaps having a SecureActionMapping subclass of 
ActionMapping that might allow declarative access control based on a 
user role or something -- but I haven't needed that kind of security 
in an app yet, so I haven't really learned all the details.

If you need it, maybe you can build it, and then contribute it back 
to the project?  That's how these things grow after all...

Joe

-- 
--
* Joe Germuska    { joe@germuska.com }
"It's pitiful, sometimes, if they've got it bad. Their eyes get 
glazed, they go white, their hands tremble.... As I watch them I 
often feel that a dope peddler is a gentleman compared with the man 
who sells records."
	--Sam Goody, 1956
tune in posse radio: <http://www.live365.com/stations/289268>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: container managed security

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 8 Jul 2002, Jürgen Weber wrote:

> Date: Mon, 08 Jul 2002 17:48:29 +0200
> From: Jürgen Weber <we...@hotmail.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: struts-user@jakarta.apache.org
> 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/struts-user@jakarta.apache.org/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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>