RE: security framework!!!
InteresTing discussion.Is there more website links on the same Thanks! Craig R. McClanahan [EMAIL PROTECTED] wrote: (Jumping in late, and trying to catch up on several hundred email messages in my STRUTS-USER folder, but better late than never ...) Quoting David Friedman : Adam, With my structure, I might have to become a particular reseller, then flip into a customer of his/hers, then become one of their client accounts to look into a reported problem. I worry about login identities for the following reasons: Using a JAAS login, my principal would be fixed (set in stone) for my session. Then, I couldn't be able to use the 'roles' settings inside Struts, Tiles, and JSPs to control content. Without using a JAAS login, I also become unable to use 'roles' in Tiles and JSPs to control content. Without having any theories on how to successfully (and without much alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at a loss how to change my identity/roles If I made a filter to wrapper the Request with a HTTPServletRequestWrapper object then added my own push/pop/depth methods, I see how I could use roles in all of those places. Knowing all of the above gory details, do you (or anyone) have any suggestions on how to make things cleaner while using roles in all of those places with the various levels of control I need to exert (albeit probably rarely switching roles) ? David, If I understand what you're after correctly, the design you have proposed is pretty troubling from a security perspective. In particular, consider what happens if your system is also logging who made what changes (so you can go audit things later). If users are allowed to impersonate each other, you have no accountability at all. From a security perspective, it is much better that each user have a unique individual identity, and that all actions taken by that individual are associated with that identity. Going back to your problem, then, have you considered that an individual user can have more than one role? For example, if you have manager and employee roles, you (as a manager) can have *both* of them assigned to your UserPrincipal, and therefore you can do anything that either a manager or an employee can do, while employees cannot execute manager functions. This is the way roles are typically used in J2EE applications, and it maps just as well to your five-level hierarchy as it does a two-level one. Thanks (to all) for any constructive suggestions, David Craig McCanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
RE: security framework!!! (Addendum to my previous post)
Hi, Has anyone tried filters framework (filter tag in web.xml) in struts for role based access to webpages in a enterprise wide application...deployed in weblogic...we tried this and seems each sub-application needs a differenet, its own web.xml and a single integrated web.xml.. Any workarounds... Thanks, Sam. (Basically, in our lare web app, we want to allow different users (admin, user, etc) access to different pages (password reset, etc) based on his privileges Thanks! ( I am quoting below. http://info.borland.com/techpubs/jbuilder/jbuilder8/webapps/webapp_dd_editor.html#filters that i did find some related info, though) as as [EMAIL PROTECTED] wrote:InteresTing discussion.Is there more website links on the same Thanks! Craig R. McClanahan wrote: (Jumping in late, and trying to catch up on several hundred email messages in my STRUTS-USER folder, but better late than never ...) Quoting David Friedman : Adam, With my structure, I might have to become a particular reseller, then flip into a customer of his/hers, then become one of their client accounts to look into a reported problem. I worry about login identities for the following reasons: Using a JAAS login, my principal would be fixed (set in stone) for my session. Then, I couldn't be able to use the 'roles' settings inside Struts, Tiles, and JSPs to control content. Without using a JAAS login, I also become unable to use 'roles' in Tiles and JSPs to control content. Without having any theories on how to successfully (and without much alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at a loss how to change my identity/roles If I made a filter to wrapper the Request with a HTTPServletRequestWrapper object then added my own push/pop/depth methods, I see how I could use roles in all of those places. Knowing all of the above gory details, do you (or anyone) have any suggestions on how to make things cleaner while using roles in all of those places with the various levels of control I need to exert (albeit probably rarely switching roles) ? David, If I understand what you're after correctly, the design you have proposed is pretty troubling from a security perspective. In particular, consider what happens if your system is also logging who made what changes (so you can go audit things later). If users are allowed to impersonate each other, you have no accountability at all. From a security perspective, it is much better that each user have a unique individual identity, and that all actions taken by that individual are associated with that identity. Going back to your problem, then, have you considered that an individual user can have more than one role? For example, if you have manager and employee roles, you (as a manager) can have *both* of them assigned to your UserPrincipal, and therefore you can do anything that either a manager or an employee can do, while employees cannot execute manager functions. This is the way roles are typically used in J2EE applications, and it maps just as well to your five-level hierarchy as it does a two-level one. Thanks (to all) for any constructive suggestions, David Craig McCanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time.
RE: security framework!!!
(Jumping in late, and trying to catch up on several hundred email messages in my STRUTS-USER folder, but better late than never ...) Quoting David Friedman [EMAIL PROTECTED]: Adam, With my structure, I might have to become a particular reseller, then flip into a customer of his/hers, then become one of their client accounts to look into a reported problem. I worry about login identities for the following reasons: Using a JAAS login, my principal would be fixed (set in stone) for my session. Then, I couldn't be able to use the 'roles' settings inside Struts, Tiles, and JSPs to control content. Without using a JAAS login, I also become unable to use 'roles' in Tiles and JSPs to control content. Without having any theories on how to successfully (and without much alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at a loss how to change my identity/roles If I made a filter to wrapper the Request with a HTTPServletRequestWrapper object then added my own push/pop/depth methods, I see how I could use roles in all of those places. Knowing all of the above gory details, do you (or anyone) have any suggestions on how to make things cleaner while using roles in all of those places with the various levels of control I need to exert (albeit probably rarely switching roles) ? David, If I understand what you're after correctly, the design you have proposed is pretty troubling from a security perspective. In particular, consider what happens if your system is also logging who made what changes (so you can go audit things later). If users are allowed to impersonate each other, you have no accountability at all. From a security perspective, it is much better that each user have a unique individual identity, and that all actions taken by that individual are associated with that identity. Going back to your problem, then, have you considered that an individual user can have more than one role? For example, if you have manager and employee roles, you (as a manager) can have *both* of them assigned to your UserPrincipal, and therefore you can do anything that either a manager or an employee can do, while employees cannot execute manager functions. This is the way roles are typically used in J2EE applications, and it maps just as well to your five-level hierarchy as it does a two-level one. Thanks (to all) for any constructive suggestions, David Craig McCanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: security framework!!!
: David Friedman To: Struts Users Mailing List Sent: Wednesday, March 17, 2004 5:48 PM Subject: RE: security framework!!! Adam, With my structure, I might have to become a particular reseller, then flip into a customer of his/hers, then become one of their client accounts to look into a reported problem. I worry about login identities for the following reasons: Using a JAAS login, my principal would be fixed (set in stone) for my session. Then, I couldn't be able to use the 'roles' settings inside Struts, Tiles, and JSPs to control content. Without using a JAAS login, I also become unable to use 'roles' in Tiles and JSPs to control content. Without having any theories on how to successfully (and without much alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at a loss how to change my identity/roles If I made a filter to wrapper the Request with a HTTPServletRequestWrapper object then added my own push/pop/depth methods, I see how I could use roles in all of those places. Knowing all of the above gory details, do you (or anyone) have any suggestions on how to make things cleaner while using roles in all of those places with the various levels of control I need to exert (albeit probably rarely switching roles) ? Thanks (to all) for any constructive suggestions, David -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 6:51 PM To: Struts Users Mailing List Subject: Re: security framework!!! 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:[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
Re: security framework!!!
David, I think it is unusual to design the security system such that you must switch identities to meet your requirements. It may be worth rethinking your security system design so that a user will remain who they are, but be allowed to access resources that fall under their responsibility. As a generic example, it is customary for a user who is a system administrator to be able to change the password for any user in the system. The administrator does not actually switch their identity in the process, but rather they are granted access to do the password change by virtue of having some kind of sysadmin role. I realize that your business domain is more complex than that, but I think it would be useful to think about it in terms of a user having access to things without having to switch their identity. Since you can't use simple system-wide roles like admin due to the structure of responsibilities dictated by your business domain (client can add and edit their employees, but not the employees of another client), you have to do something special. One option is to map (flatten) the complex domain to a flat set of roles. For example, client Bob has role client1234.client, where client1234 is the client that Bob is a client for. You might also have roles like admin, reseller33, customer128, client1234.employee, etc. The numbers in in the role names are the id of the entity they represent. This requires programmatic security in a sense, since you will need to determine what role to check for at runtime. But you will still be able to use the J2EE standard request.isUserInRole() call to determine membership for the currently authenticated user. Another option is to do thoroughly programmatic security, where you still use container-managed security for authentication (is this Bob?) and write code to do the authorization (Bob wants to edit a user account in the context of the client with id = 1234, is Bob allowed to do that?) without mapping it to a role name. Perhaps your realm could create Principal objects such that the application code can ask the Principal if they can do something. Bob will very likely have other responsibilties (the same stuff the employees do) that you might wish to control with a single role client1234.employee. In that case, Bob would have both the client1234.client and client1234.employee roles. Alternately, you could identify a set of roles that would allow a user to do that stuff: client1234.employee, client1234.client, customer128, reseller33, etc. where client1234 is under the customer128 account, which in turn is under the reseller33 account. If Bob had any of those roles, he would be allowed to do employee stuff in the context of client1234. A single user can have an unlimited number of roles, and you can write your own security realm to read that information from a variety of tables in the database. Or write a view in the database for your User_Role join table and use a standard realm. Be aware that you might end up wasting a lot of memory if each user ends up with a ton of roles and your realm loads them all into memory during authentication. I have not done anything with JAAS, so perhaps there is a better solution available using JAAS technology. It would be great to hear from someone that knows of a good JAAS-based solution. David's problem of entity-based (rather than system-wide) responsibilities is a very common one. -Max - Original Message - From: David Friedman [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 5:48 PM Subject: RE: security framework!!! Adam, With my structure, I might have to become a particular reseller, then flip into a customer of his/hers, then become one of their client accounts to look into a reported problem. I worry about login identities for the following reasons: Using a JAAS login, my principal would be fixed (set in stone) for my session. Then, I couldn't be able to use the 'roles' settings inside Struts, Tiles, and JSPs to control content. Without using a JAAS login, I also become unable to use 'roles' in Tiles and JSPs to control content. Without having any theories on how to successfully (and without much alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at a loss how to change my identity/roles If I made a filter to wrapper the Request with a HTTPServletRequestWrapper object then added my own push/pop/depth methods, I see how I could use roles in all of those places. Knowing all of the above gory details, do you (or anyone) have any suggestions on how to make things cleaner while using roles in all of those places with the various levels of control I need to exert (albeit probably rarely switching roles) ? Thanks (to all) for any constructive suggestions, David -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 6:51 PM To: Struts Users Mailing List Subject: Re
Re: security framework!!!
JAAS won't help you any more than what you've got in tomcat. The use of roles operates on exactly the same principles. It's got to, because it's not JAAS that has to deal with the roles, it's the container. JAAS allows multiple login modules to be combined in a pluggable fashion. Say a user/password with a smartcard and a biometric scanner. (perhaps Sun are trying to sell it to the Pentagon!) I'm not helping much here, but I still don't get what the problem is. I read the bit about 'entity-based not system-wide' responsibilities and I get that, but I don't see what the issue is. You're deciding permissions: you have a user's identity (ID or login name) and you have a user's roles. In this case, your superuser wants to 'become' a normal user, so that means to me that the superuser wants to see exactly what the user sees, and be able to do exactly what the user can do. That means the superuser must borrow the user's identity and roles. To borrow the identity, you use some sort of session attribute containing the 'currently effective ID' and to borrow the roles, well you don't, you just have them already because you're superuser. Perhaps a concrete example would help. I assume you are talking about deciding on the presence / absence of form controls depending on the user viewing the page. Adam On 03/18/2004 09:34 AM Max Cooper wrote: David, I think it is unusual to design the security system such that you must switch identities to meet your requirements. It may be worth rethinking your security system design so that a user will remain who they are, but be allowed to access resources that fall under their responsibility. As a generic example, it is customary for a user who is a system administrator to be able to change the password for any user in the system. The administrator does not actually switch their identity in the process, but rather they are granted access to do the password change by virtue of having some kind of sysadmin role. I realize that your business domain is more complex than that, but I think it would be useful to think about it in terms of a user having access to things without having to switch their identity. Since you can't use simple system-wide roles like admin due to the structure of responsibilities dictated by your business domain (client can add and edit their employees, but not the employees of another client), you have to do something special. One option is to map (flatten) the complex domain to a flat set of roles. For example, client Bob has role client1234.client, where client1234 is the client that Bob is a client for. You might also have roles like admin, reseller33, customer128, client1234.employee, etc. The numbers in in the role names are the id of the entity they represent. This requires programmatic security in a sense, since you will need to determine what role to check for at runtime. But you will still be able to use the J2EE standard request.isUserInRole() call to determine membership for the currently authenticated user. Another option is to do thoroughly programmatic security, where you still use container-managed security for authentication (is this Bob?) and write code to do the authorization (Bob wants to edit a user account in the context of the client with id = 1234, is Bob allowed to do that?) without mapping it to a role name. Perhaps your realm could create Principal objects such that the application code can ask the Principal if they can do something. Bob will very likely have other responsibilties (the same stuff the employees do) that you might wish to control with a single role client1234.employee. In that case, Bob would have both the client1234.client and client1234.employee roles. Alternately, you could identify a set of roles that would allow a user to do that stuff: client1234.employee, client1234.client, customer128, reseller33, etc. where client1234 is under the customer128 account, which in turn is under the reseller33 account. If Bob had any of those roles, he would be allowed to do employee stuff in the context of client1234. A single user can have an unlimited number of roles, and you can write your own security realm to read that information from a variety of tables in the database. Or write a view in the database for your User_Role join table and use a standard realm. Be aware that you might end up wasting a lot of memory if each user ends up with a ton of roles and your realm loads them all into memory during authentication. I have not done anything with JAAS, so perhaps there is a better solution available using JAAS technology. It would be great to hear from someone that knows of a good JAAS-based solution. David's problem of entity-based (rather than system-wide) responsibilities is a very common one. -Max - Original Message - From: David Friedman [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 5:48 PM Subject: RE: security framework!!! Adam
RE: security framework!!!
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
Re: security framework!!!
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:[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
RE: security framework!!!
Adam, With my structure, I might have to become a particular reseller, then flip into a customer of his/hers, then become one of their client accounts to look into a reported problem. I worry about login identities for the following reasons: Using a JAAS login, my principal would be fixed (set in stone) for my session. Then, I couldn't be able to use the 'roles' settings inside Struts, Tiles, and JSPs to control content. Without using a JAAS login, I also become unable to use 'roles' in Tiles and JSPs to control content. Without having any theories on how to successfully (and without much alteration to the package[s]) use roles for Struts, Tiles, and JSPs, I'm at a loss how to change my identity/roles If I made a filter to wrapper the Request with a HTTPServletRequestWrapper object then added my own push/pop/depth methods, I see how I could use roles in all of those places. Knowing all of the above gory details, do you (or anyone) have any suggestions on how to make things cleaner while using roles in all of those places with the various levels of control I need to exert (albeit probably rarely switching roles) ? Thanks (to all) for any constructive suggestions, David -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 6:51 PM To: Struts Users Mailing List Subject: Re: security framework!!! 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:[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
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]
RE: security framework!!!
Adam, 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. 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
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
RE: security framework!!!
Hi David, Would this be consider a user delegation model that you are trying to built? I came across this article Security in Struts: User Delegation Made Possible when doing my research not sure would it help you Thought just let you take a look see if it help... as I myself is oso a noob in struts... http://www.onjava.com/pub/a/onjava/2004/02/18/strutssecurity.html God Bless, Benz Lim -Original Message- From: David Friedman [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 10:00 PM To: Struts Users Mailing List Subject: RE: security framework!!! Adam, 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. 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
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]
RE: a security framework!
Hi, As I fond the logic:present and logic:notPresent tags does support the JAAS frame work. They have an attribute called role. I have not mentioned that before! Surprising no one mentioned it. Why?! Is there some thing wrong with using this tag! Thanks -Original Message- From: Daniel Lipofsky [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 2:37 AM To: Struts Users Mailing List Subject: RE: a security framework! I did something similar. I extended each struts HTML tag to take a rule and evaluate it in doStartTag. It then returns SKIP_BODY to hide it or super.doStartTag() to show it. Similarly doEndTag() returns EVAL_PAGE to hide it or super.doEndTag() to show it. I actually have 3 security levels and I call setDisabled() to disable the field if it is visible but not editable. It's not hard. - Dan -Original Message- From: Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 8:17 PM To: [EMAIL PROTECTED] Subject: a security framework! Hi, I'm developing a web application with struts framework.I want to design some jsp pages that support security at pages level.The security that I want to be supported is that some components of each page can be shown for certain user.I mean that for each user deponds on his access to the system we can show some components of each page and does'nt show other components.Each user deponds on his type and access at the system just can see his own pages.can you offer a good framework for this goal that be compatible with struts framework. Regards - 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]
Re: a security framework!
Support the JAAS framework? Directly? Don't you mean the container-managed security? On 03/14/2004 01:21 PM Mailing List wrote: Hi, As I fond the logic:present and logic:notPresent tags does support the JAAS frame work. They have an attribute called role. I have not mentioned that before! Surprising no one mentioned it. Why?! Is there some thing wrong with using this tag! Thanks -Original Message- From: Daniel Lipofsky [mailto:[EMAIL PROTECTED] Sent: Friday, March 12, 2004 2:37 AM To: Struts Users Mailing List Subject: RE: a security framework! I did something similar. I extended each struts HTML tag to take a rule and evaluate it in doStartTag. It then returns SKIP_BODY to hide it or super.doStartTag() to show it. Similarly doEndTag() returns EVAL_PAGE to hide it or super.doEndTag() to show it. I actually have 3 security levels and I call setDisabled() to disable the field if it is visible but not editable. It's not hard. - Dan -Original Message- From: Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 8:17 PM To: [EMAIL PROTECTED] Subject: a security framework! Hi, I'm developing a web application with struts framework.I want to design some jsp pages that support security at pages level.The security that I want to be supported is that some components of each page can be shown for certain user.I mean that for each user deponds on his access to the system we can show some components of each page and does'nt show other components.Each user deponds on his type and access at the system just can see his own pages.can you offer a good framework for this goal that be compatible with struts framework. Regards - 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]
RE: security framework!!!
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]
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]
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]
RE: security framework!!!
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]
RE: security framework!!!
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]
RE: security framework!!!
http://sourceforge.net/projects/securityfilter/ emulates container managed security. robert -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]
RE: security framework!!!
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 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]
RE: security framework!!!
Oracle provides Single Sign On with OID - no extra work required. -Original Message- From: David Friedman [mailto:[EMAIL PROTECTED] Sent: Saturday, March 13, 2004 8:49 AM To: Struts Users Mailing List Subject: RE: security framework!!! 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 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: security framework!!!
Thanks a lot for your response.I 'm so interesting to know that which of the three framework you use.all of them combine together or no just one of them.and give me a sample of your configuration. regards -Original Message- From: Dmitry Brin [mailto:[EMAIL PROTECTED] Sent: Sunday, March 14, 2004 1:08 AM To: 'Struts Users Mailing List' Subject: RE: security framework!!! Oracle provides Single Sign On with OID - no extra work required. -Original Message- From: David Friedman [mailto:[EMAIL PROTECTED] Sent: Saturday, March 13, 2004 8:49 AM To: Struts Users Mailing List Subject: RE: security framework!!! 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 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] - 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]
Re: a security framework!
I would start by looking at Tiles - you can associate roles using tiles. If you are using XML configuration, you can associate a role with a definition definition name=my.tile.definition path= role=myRole /definition Also the tiles tags tiles:insert page=.. role=... tiles:definition template=.. role=... tiles:put name=.. value= role=... tiles:add value=.. role=... tiles:get value=.. role=... To find out more about tiles: http://jakarta.apache.org/struts/userGuide/dev_tiles.html http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf Also there is a tiles-documentation.war shipped with struts Niall - Original Message - From: Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 11, 2004 4:16 AM Subject: a security framework! Hi, I'm developing a web application with struts framework.I want to design some jsp pages that support security at pages level.The security that I want to be supported is that some components of each page can be shown for certain user.I mean that for each user deponds on his access to the system we can show some components of each page and does'nt show other components.Each user deponds on his type and access at the system just can see his own pages.can you offer a good framework for this goal that be compatible with struts framework. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: a security framework!
I did something similar. I extended each struts HTML tag to take a rule and evaluate it in doStartTag. It then returns SKIP_BODY to hide it or super.doStartTag() to show it. Similarly doEndTag() returns EVAL_PAGE to hide it or super.doEndTag() to show it. I actually have 3 security levels and I call setDisabled() to disable the field if it is visible but not editable. It's not hard. - Dan -Original Message- From: Mailing List [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 8:17 PM To: [EMAIL PROTECTED] Subject: a security framework! Hi, I'm developing a web application with struts framework.I want to design some jsp pages that support security at pages level.The security that I want to be supported is that some components of each page can be shown for certain user.I mean that for each user deponds on his access to the system we can show some components of each page and does'nt show other components.Each user deponds on his type and access at the system just can see his own pages.can you offer a good framework for this goal that be compatible with struts framework. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
a security framework!
Hi, I'm developing a web application with struts framework.I want to design some jsp pages that support security at pages level.The security that I want to be supported is that some components of each page can be shown for certain user.I mean that for each user deponds on his access to the system we can show some components of each page and does'nt show other components.Each user deponds on his type and access at the system just can see his own pages.can you offer a good framework for this goal that be compatible with struts framework. Regards
