Thanks for the info, and I'll get into that at some point.
But from reading the initial docco on JAAS, it's for security based for
"user-based, group-based, or role-based access controls".
Unless I'm not seeing something I should, the security being discussed
here isn't defined by any of those. It's simply an extra mechanism by
which the struts servlet can verify that it's to set a property based on
extra security properties passed in the request so that a hostile user
can't just type in name value pairs and alter properties. This would be
set up as a part of the app/bean configuration, not based on a user
authentication scheme, as it doesn't change content, what the user can
or can't do etc.
I think that the best solution would be to put a default security
property in the action form class, and that way the use of the feature
would be transparent to everyone. It'd just suddenly start working when
they update the struts packages.
A heavier grained approach could be used to put an extra key against
each property to be set, but I think that this is a little overboard, as
it would have to be configured and coded into each bean, and wouldn't be
any more secure than the default method described above.
[EMAIL PROTECTED] wrote:
>The Java security mechanism is quite easy to use. The main classes are:
>
>1) Subject - defines a person - contains several Principals, and has
>methods to allow code to be executed as a given Principal.
>2) Principal - sort of like a role that a person has. The primary
>Principal is the one that defines who a person is, the others are roles
>that they have.
>3) Permission - used to both grant and verify privileges. The general
>usage is something like this:
>4) SecurityManager -used to check permissions and run code as a given
>user, or to temporarily get extra permissions
>5) Policy - defines what a subject, or code is allowed to do, contains
>Permission's associated with a given Principal
>
>public void function(Argument a1, Argument a2) {
> SecurityManager.checkPermission(new MyPermission("function", a1));
> // rest of body to execute function
>}
>
>where you have defined MyPermission to be a sub-class of Permission that
>takes an operation name ("function" in the example), and some parameters
>(if needed.)
>Then, you can call this method using code similar to:
>
>Subject subject = (Subject) request.getProperty("Subject");
>subject.doAs(subject, new PrivilegedAction() { public Object run() {
>function(a1,a2); } };
>
>Generally, the doAs part is handled by the framework as part of a wrapper
>around executing action.
>
>The Policy must map Principals to a set of Principals, and then each
>principal is checked to see if it can grant "MyPermission".
>By default AllPermission grants any permission at all, and since it is only
>one permission, it is granted very quickly.
>If there are lots of permissions to check, then there are ways to make this
>all work very quickly, usually just the cost of a single check permission
>call, and a single hash map lookup (Ask me about this only after you
>understand the rest of the basic concepts.)
>
>To get a subject, there is generally a DB table that maps login id's to an
>array of subjects, and as part of the login process, the Subject is put
>into the session object.
>
>Note that this systems is extremely flexible, while also being very easy to
>use for minimalist security. You can do things like requiring a new
>password to be entered if the user attempts to use certain permissions.
>You can also automatically dis-allow JSP or servlet pages to be viewed by
>putting checkPermission's into the servlet/JSP page, or else check a
>permission and remove a portion of a page based on security settings.
>Because there is already a fairly complete policy file parser, you can use
>that to start working with permissions, and only change over to a more
>complete system later on (or not if it isn't needed.)
>
>Bill Wallace
>
>(716) 214-8872
>Fax: (716) 295-4718
>Element K
>'the knowledge catalyst'
>www.elementk.com
>
>
>
>
> "Lacerda,
>
> Wellington (AFIS)" To: "'[EMAIL PROTECTED]'"
><[EMAIL PROTECTED]>
> <Wellington.Lacerd cc:
>
> [EMAIL PROTECTED]>
>
> Subject: RE: Extensibility of
>struts & Property Security
> 11/28/01 09:35 AM
>
>
>
>
>
>
>
>
>
>
>I'd like to have more info on that!
>
>Wellington
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, November 28, 2001 3:29 PM
>To: Struts Developers List
>Subject: Re: Extensibility of struts & Property Security
>
>
>
>Please use the standard java security mechanism, rather than trying to
>invent a new one. The standard mechanism is very general, and allows very
>fast checks when security is turned off, and conversely, allows very
>fine-grained security checks to be made. I have implemented this in a
>web-model and it works quite well. Send me email if you want more
>information on using it, preferably after you read the java documentation
>(look at JAAS).
>
>Bill Wallace
>
>(716) 214-8872
>Fax: (716) 295-4718
>Element K
>'the knowledge catalyst'
>www.elementk.com
>
>
>
>
> Arron Bates
>
> <arron@keyboardm To: Struts Developers List
><[EMAIL PROTECTED]>
> onkey.com> cc:
>
>
>
> 11/27/01 08:45 Subject: Re: Extensibility
>of
>struts & Property Security
> PM
>
> Please respond
>
> to "Struts
>
> Developers List"
>
>
>
>
>
>
>
>
>
> Yes, yes. Point made.
>That series of emails makes for some good bedside reading.
>
>
>I think that the solution that was arrived at is fine for protecting the
>struts system objects themselves.
>Is there anything happening to allow the developer to protect their own
>properties from this kind of arbitrary attack?
>
>Thought I had would be to configure a property modifier, or property
>mapping which yields other "security properties" which have to be
>checked before a property is set. ie: getMyProperty() property method
>uses a getMyPropertySecurity() to return a defined value which was set
>while writing the view so you can't just pass the one key value pair to
>change a value, but a two key value pairs with the second value being a
>specific hashing or such. This would stop the casual hacking of any
>property via the URL. You could also then define a security property for
>all things struts within the ActionForm.
>
>The possibility then in extending this would be to define a security
>property to each property to be set, or a more simpler global security
>property for the entire request, and let the developer decide as to how
>fine grained the property setting security should be, if at all.
>
>Just a thought.
>
>
>Arron.
>
>
>Ted Husted wrote:
>
>>http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813
>>
>>"So, someone could also call
>>
>>getServlet().setTempDir(whatever)
>>
>>with
>>
>>http://whatever.com/do/someAction?servlet.tempdir=whatever
>>
>>Hmmm."
>>
>>-- Ted Husted, Husted dot Com, Fairport NY USA.
>>-- Custom Software ~ Technical Services.
>>-- Tel +1 716 737-3463
>>-- http://www.husted.com/struts/
>>
>>
>>Arron Bates wrote:
>>
>>>It doesn't even have to be a careful look at the code. It's not complex
>>>in the least.
>>>
>>>I must be missing something with the "String or boolean properties that
>>>affect the system state" thing.
>>>
>>>Do you mean what it is that I do with the example, where I have a string
>>>property that represents a submit button that add objects to the tree
>>>and another that can delete them?... If it isn't, can I get an
>>>
>example?...
>
>>>Arron.
>>>
>>--
>>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]
>
>
>
>
>
>
>
>--
>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]>
