Adam, They might need to go into the account underneath them to fix something (if they are asked) and won't know the password (encrypted). The admin might need to fix something for a reseller's client made us look into (admin -> reseller -> client -> manager -> employee).
Regards, David -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Sunday, March 14, 2004 6:28 PM To: Struts Users Mailing List Subject: Re: security framework!!! You mean you don't want to force the user to log out and back in again? I would have thought that was a reasonable demand since they are effectively changing their identity. Your HttpServletRequest wrapper sounds OK as a solution though. Adam On 03/14/2004 03:51 PM David Friedman wrote: > Adam, > > I want to integrate everything with roles (for using actions and jsp tags) > so I'm stuck, after container authentication, having a non-changeable > Principal object within Tomcat: their Coyote HttpServletRequest wrapping > class prevents the use of setUserPrincipal. All of my research on Tomcat (4 > or 5) suggests a filter-based wrapper for the HttpServletRequest object is > the only way to go to be able to set the UserPrincipal from within my action > so I could replace the Principal (as the admin becomes the reseller becomes > the customer becomes the manager becomes the user account, etc. and possibly > backs out each level one by one). > > Can you suggest any other avenues or theories for me to investigate since my > research has resulted in only that one workable solution? Hints > appreciated. :) > > Regards, > David > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 14, 2004 5:21 AM > To: Struts Users Mailing List > Subject: Re: security framework!!! > > > On 03/13/2004 05:48 PM David Friedman wrote: > >>My bigger problem is my scenario, which no one supports. I'd like to > > allow > >>manager accounts to become one of if it's sub-accounts. My system would >>support at least 5 levels where 4 could 'drill down' and back up again: >>admin, reseller, client, manager, employee (bottom feeder, no managerial >>tools and no popping into their accounts). Since there is no easily way > > to > >>push/pop or even set (then I could use my own internal stack) a >>UserPrincipal object, I'm thinking of using something a bit like >>SecurityFilter: > > > I'm not sure why the standard container-managed security roles don't > meet your requirements. > > You want a manager to be able to set himself to another role? Sounds > like a design issue. Obviously the manager is also going to need to set > himself back to his normal role again? > > I would use extra roles to allow changing roles. The manager can assign > himself whatever standard role he likes depending on his 'extra' roles. > This would change the info in your realm and he would have to log out > and back in again. > > Or have I got the wrong end of the stick? > > Adam > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
