struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: security framework!!!
Date Wed, 17 Mar 2004 23:50:55 GMT
I don't see your requirement for replacing the principal when the admin
wants to 'become' someone else. What are you envisaging that such a
technique would bring? How are you planning for the administrator to get
his/her original user back?

I'm pretty confident you can accomplish this through the judicious use
of roles. OK, you'll need quite a few admittedly.

Unless I've missed a point somewhere.

On 03/17/2004 11:54 PM David Friedman wrote:
> 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:ahardy.struts@cyberspaceroad.com] 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:ahardy.struts@cyberspaceroad.com] 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:jason@kumachan.net.nz] 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:mailinglist@pdpsoft.com] Sent: Saturday, March 13, 2004
>>>>  6:19 AM To: struts-user@jakarta.apache.org 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message