Again comments below ;)

Regards,

Nic
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 29, 2001 12:07 PM
Subject: Re: Role-based security


> There are a number of problems with deploying container-based security.
> It's an important feature, but it doesn't seem like a panacea.
>
> What I would suggest is that we look at Nic's proposal from the
> viewpoint of being able to also implement FORM-based security, using the
> standard Java packages.
>
This is how I envisaged it. I don't think it is possible to come up with a
solution that is useable on all platforms at the moment if it is not based
on the way the specs dictate security - however insufficient that is.

> Craig's mentioned that it's not possible to set the role programatically
> when container-based security is used, presumably because the container
> does it. But I've been wondering if it is possible to set it
> programatically when the container does NOT use it. For example, could
> the controller set the role for every request -- instead of the
> container.
>
I wonder how much of this would be container specific? Can we
programmatically set the role so that it is accessible from the isUserInRole
calls to stay standard?


> Roles are helpful, but I think many real-life applications also need to
> look at groups and permissions. If we had a security framework that
> worked with or without the container's help, it would be worthwhile to
> build fine-grained security into other parts of Struts.
>
I agree. This was only a first draft based on the particular requirement in
the TODO. I wonder though whether those with clout at sun should force a
rethink in the J2EE security architecture though as most people I speak to
think it is insufficient and even JAAS has its holes. I think us coming up
with a struts way of doing things is good for a webapp but when the security
context has to be propogated across to the EJB layer for standard security
(or even custom security) at that level we may have problems. Perhaps we
should start up a discussion on this separately as this is likely to be a
big piece of work that many will want to contribute to (ideas of not
implementations anyway!). Comments?

Again thanks for your input Ted.


> -Ted.
>
> PS - In related news, the slides from Craig's BOF on authentification
> are available for download at More About Struts (Star Office format).
>
> < http://husted.com/about/struts/resources.htm#new >
>
>
> Oleg V Alexeev wrote:
> >
> > Hello Nic,
> >
> > Hm... Nic, I think that 'roles' attribute in ActionMapping is not
> > solution - it helps to check path based security. So we have container
> > security and struts security on one way - is it right? And more - one
> > of the hard errors in J2EE projects is custom security mechanism
> > (sorry, I forget URL to resource... :( )
> >
> > But more generally, your approach is interesting, I like it. If we
> > must check access level for the function, not path, then it is good
> > solution. I think every developer in struts community some day take a
> > look to the security problem in his application - and your solution
> > can be standart way to solve it.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Reply via email to