If you use something like one of the mod_ldap implementations for apache the
admin would have his password in the ldap directory. I also am pretty sure
that there is a auth module for apache that uses a database like MySQL. In
that case the admins id and password would be in the database. So when he
changes his password he does not have to restart the application. The apache
modules would respect the fact that he authenticated to either the directory
or the database and authorize access to the application.
In either case the authorization and access control for individual URL's for
the web server (and your application) would be regulated by the apache
module and not by your application.
In my estimation, building security mechanisms into Struts will be a
slippery slope downhill. It is something that is best suited for the
existing apache authorization and access modules or other external security
mechanisms. I can see that it would be a good thing for creating a project
to extend some of the existing apache auth and access modules to incorporate
protecting servlets and EJB's. A number of them already can control
authorization and access control for web servers and individual URLs.
If you go to the Apache module registry and do a search on "auth", "ldap" or
I think "access" you will find quite a few modules that can probably suit
your needs. There is one particular mod_ldap that I think is better than the
others but there are quite a few to choose from and I think that many would
fulfill most peoples needs.
If you are using either a database or a directory you can also use them to
supply user and group attributes to control the access to different
functions in your application by checking the attributes for the user or
group and displaying or not displaying something like a button or menu
selection in the page. You could use the LDAP or DB taglibs for doing things
like this in conjunction with the external security mechanism that would be
protecting the access to the URLs.
But the actual protection of the URLs should be external to the app.
I would say look elsewhere for security for your applications and do not in
build it into the Struts framework.
.
----- Original Message -----
From: "Manabendra Sarkar" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "'Martin Duffy'" <[EMAIL PROTECTED]>
Sent: Tuesday, May 08, 2001 8:08 AM
Subject: RE: Potential Security Flaw in Struts MVC
> but if i use external security mechanism, will it be dynamic? i mean to
say,
> if the admin wants to change his/her password from the application
> (using admin interface), how can he/she do that without restarting the
> server?
>
> > -----Original Message-----
> > From: Martin Duffy [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, May 07, 2001 5:57 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Potential Security Flaw in Struts MVC
> >
> > A basic problem with most web development is that people are building
> > security into their applications. It should be handled outside of the
> > application. You can have your application work in conjunction with an
> > external security mechanism for more granular control but I the security
> > mechanism should be external to the application for the most part.
> >
> > You could use for example one of the authorization and access modules
for
> > apache. Then when you create your application you can create specific
> > *protected* URLs for say an admin area. Then only the person that is
> > logged into the security mechanism with the proper *authorization* can
> > access that URL (or one that contains that URL and parameters being
passed
> > to it in the URL). Security needs to be considered when building the
> > applications but trying to build it into the application is a big
mistake.
> >
> >
> > A big reason to not build it into the app is that as your security
> > requirements change you invariably have to make code changes to your
> > application. By using an external mechanism you just change the rules
> > governing the authorization and access control usually without any code
> > changes to your app.
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: Jeff Trent <mailto:[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>
> > Sent: Monday, May 07, 2001 6:37 PM
> > Subject: Potential Security Flaw in Struts MVC
> >
> > I may be wrong about this (only been working w/ Struts for a week
> > now). But I do see a potential security flaw in struts that I would
like
> > to hear from others regarding.
> >
> > Consider a simple set of struts classes that represent a user in a
> > system. You would probably have classes that look something like this:
> > User (the model representing the user)
> > UserForm (an enrollment form for a new user)
> > UserAction (Saves the UserForm information to db, etc)
> >
> > The User class would have accessors and modifiers like
> > getFirstName(), setFirstName(), getAdministrativeUserFlag(),
> > setAdministrativeUserFlag(), etc. The basic implementation of the
> > UserForm is to take the UI form data, introspect the beans, and call the
> > correct modifier of the UserForm bean based on the fields contained
within
> > the UI submission/form. A developer of course would not expose the
> > "Administrative User Flag" option on the UI for enrollment (that would
be
> > found possibly in some other administrative-level module). However, if
> > someone is familiar with the db schema and the naming convention the
> > developer used, that user could subvert the application by writing his
own
> > version of the UI which contains an "Administrative User Flag" field (or
> > any other field for that matter) and the basic form processing in Struts
> > will kindly honor the request and set the "Administrative Flag" on the
> > user. Unless, of course, the developer makes special provisions to
> > prevent this behavior. However, its not entirely obvious to the struts
> > user (in my opinion) that this is even a concern. Am I making sense
here?
> >
> > - jeff
> >
> >
>
