Andy, My personal project will have 5 distinct levels (a business of my own, someday). The lowest level has individual powers, nothing shared. It makes that particular level analogous to a shopping cart user: his/her 'stuff' only. The groups/levels are in order from highest ability to lowest (the individual user). They can only become or manipulate the level below them directly, unless they assume the identity of an account they manage to review/fix/look into something. The descriptions of the levels follow:
Senior Group level "administrators". For all intent and purposes, that is me and my team. We can add/edit/remove/become/lock-down any reseller account (only upon request, of course). Junior Group level - "reseller company". A reseller company has a group of accounts (one or more) who can add/edit/remove/become/lock-down any of their own customer accounts (hopefully only upon request). Sophomore Group level - "customer company". A customer company is a business sold to by a "reseller". This group can add add/edit/remove/become/lock-down any of their own "clients" (again, hopefully only upon request). Freshman Group level - "client". A "client" is a corporate entity receiving services from their particular vendor, an above-mentioned "customer company". This group of accounts can add/edit/remove their own list of employees (i.e. "end users"). They have some features specific to them as well as being able to enter information similar to their individual employees. (Lowest) User level - "employee". An "employee" is an individual account under a corporate entity (in a "client"). They have individual duties and can enter data. Some of their activities may end up going to a manager (at the "client" level) for approval, depending on the activity. Essentially, all of the work they do can be seen by no one else (though a manager might need to approve certain types of request). Regards, David -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 10:28 AM To: Struts Users Mailing List Subject: Re: security framework!!! On 03/15/2004 03:00 PM David Friedman wrote: > I should have explained this a bit better. Each level is like a company or > organization. It has it's own group of parties to maintain but can be > managed by one or more managers. The managers share group responsibility. > Only the user at the very bottom rung has an interface which only that user > can use. What do you mean by that last sentence? Why can't a manager use that interface too? Surely it depends on roles? >Everyone above it is some sort of manager for maintaining there > shared group (separate from other resellers, or separate from other). > > admin--- reseller1 (admin1, admin2, admin3) -- customer1 > customer2 > customer3 > reseller2 (admin4) - customer4 > customer5 > reseller3 (admin5, admin6) - customer6 > reseller7 (admin7, admin8, admin9) - customer7 > customer8 > > In the above tree, the customer(s) have a group of their own admins plus > individual employees (who have no shared responsibilities). > > I know this sounds like I should use pow2acl but it doesn't seem to have > anything for replacing the Principal so I could become a user, nor does it > appear to have anything to let me hook SSLext into it to ensure good > http/https lock-downs. > > Do you have any hints/suggestions for a better methodology/way? > > Regards, > David > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Monday, March 15, 2004 4:25 AM > To: Struts Users Mailing List > Subject: Re: security framework!!! > > > Right, I get it. So you not only want the higher level user to take on > the lower level user's role, you want them to have their complete ID or > username etc. > > Tricky! > > I think alot depends on what kind of use you have for the user info. Is > it purely roles that are important here? Or is there ownership too? I > mean, one user can see his / her stuff, which is not accessible to > another user of equal level? > > On 03/15/2004 03:39 AM David Friedman wrote: > >>Jason, >> >>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). I've had a few projects where >>someone 2 levels under asks for help from the level immediately above > > them. > >>Then it goes up one and up again back to me. Rather than make interfaces >>for everyone for everything, I prefer the idea of "su'ing" into the > > account > >>to fix something. So, I might have to 'become' the reseller (I'm the >>admin), then become a client, then become a manager then become an > > employee > >>to look at or fix something for them. >> >>Regards, >>David >> >>-----Original Message----- >>From: Jason Lea [mailto:[EMAIL PROTECTED] >>Sent: Sunday, March 14, 2004 6:49 PM >>To: Struts Users Mailing List >>Subject: Re: security framework!!! >> >> >>David Friedman wrote: >> >> >> >>>I've also been looking into security frameworks and the only solutions > > I've > >>>really found are: >>> >>>1. Standard (container) JAAS >>>2. SecurityFilter http://securityfilter.sourceforge.net >>>3. Pow2ACL http://pow2acl.sourceforge.net/ >>> >>>I was hoping, at some point, to use an SSL switching feature such as >> >>SSLext. >> >> >>>>From my research, Pow2ACL and SecurityFilter won't work that way. >>>SecurityFilter has a note that certain 'elements' could be used for it but >>>the current code makes no use of them in that manner. As for Pow2ACL, I >>>didn't find anything suggesting how to use it in that way either. >>> >>>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 > >>> >>Trying to figure out what you are asking here can you give an example? >> >>If you have the following: >>1. User Manfred is a manager >>2. User Emily is an Employee >>3. Emily is an employee under Manfred >> >>Are you saying that Manfred can become Emily and perform certain >>tasks/actions? Then Manfred would return to be Manfred the manager? >> >> >> >>>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: wrap the request object with a subclass of >>>HttpServeletRequestWrapper and add my own push/pop/set/get/count >>>UserPrincipal object(s). Then, I could hook the login procedure with >>>container methods (JAAS, i.e. a web browser login/password pop-up) and >> >>still >> >> >>>be able to (when I'm ready) use SSLext or something like it for the >>>HTTP/HTTPS switching. >>> >>>Regards, >>>David >>> >>>-----Original Message----- >>>From: Mailing List [mailto:[EMAIL PROTECTED] >>>Sent: Saturday, March 13, 2004 6:19 AM >>>To: [EMAIL PROTECTED] >>>Subject: security framework!!! >>> >>> >>>I'm developing a web application with struts.I had a problem for support >>>security at jsp pages level for different roles.I send an email and > > recived > >>>2 response to solve my problem: >>>1. with HTML tags. >>>2. 2.with define role in tiles definition >>>but I'm searching for a good framework that be compatibled with struts >>>framework and support the security for different roles at page levels. >>>I mean for example if I have a jsp page with tow textfields and a submit >>>deponds on user's role at the system,one user just can see one of the >>>textfield and submit buttom and another user can see both of the textfield >>>and submit buttom. >>>Can you suggest a good framework for me. >>>regards >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> >> >> >>-- >>Jason Lea >> >> >> >>--------------------------------------------------------------------- >>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] > > -- 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]
