case study with security
There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you are going to play the game of trial and error, don't be surprised when the results are revealing. -- me - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
In your case, you can make administrator is a 'user' itself so that /EditAccount.do works for both roles. However, I strongly suspect your action/view you have to do lots of if else block to determine what to do and what to display. Encapsulation is the key here, I would provide 2 separate actions, one for the normal current login user and one for administrator to edit any user account. -Dan - Original Message - From: Dan Allen [EMAIL PROTECTED] To: Struts-User List [EMAIL PROTECTED] Sent: Sunday, March 23, 2003 11:03 AM Subject: case study with security There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you are going to play the game of trial and error, don't be surprised when the results are revealing. -- me - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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: case study with security
BTW,the current login user can only change his/her own login/acount profile -D - Original Message - From: Dan Tran [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Sunday, March 23, 2003 11:16 AM Subject: Re: case study with security In your case, you can make administrator is a 'user' itself so that /EditAccount.do works for both roles. However, I strongly suspect your action/view you have to do lots of if else block to determine what to do and what to display. Encapsulation is the key here, I would provide 2 separate actions, one for the normal current login user and one for administrator to edit any user account. -Dan - Original Message - From: Dan Allen [EMAIL PROTECTED] To: Struts-User List [EMAIL PROTECTED] Sent: Sunday, March 23, 2003 11:03 AM Subject: case study with security There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you are going to play the game of trial and error, don't be surprised when the results are revealing. -- me - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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: case study with security
A good practice is to use decelrative Container Managed Security. This kind of implies you set it up in web.xml (via a /securePath/*) or via action mapping in struts config. (writing you own security is not a good parctice, IMO) hth, V (do not cofuse that with the non container based filter implementation of above available from sf.net) Dan Allen wrote: There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
Dan Allen wrote:
There have been several discussions on this list about how security
should be loosely coupled with the ActionServlet itself (a filter on
top of the application), but I am curious to know the best
practicing for handling the following type of case.
Assume I have an action with a path of /EditAccount. Naturally if a
user is not logged in, this path should be protected via filtering.
However, /EditAccount has two purposes, one for the regular user to
edit his/her own account, but also for the administrator to edit any
user account via the query string ?user=username. In this case, I
have to check in the action class if the user is allowed to take on
the role of another user in which case the form is populated with
that user's data or, if not, the form should populate with the
user's own data.
Is this something that is reasonable to do in the action, or should
I create another action path /EditUserAccount?user=username and
filter that to only admins and then forward to the /EditAccount once
the proper credientials have been established, hence relieving the
action behind /EditAccount from looking at any roles?
Assuming that you are using container-managed security and roles, you
can do it with one action by having the action ignore the user parameter
unless the user is an administrator. You can check if the user is an
administrator using
if (request.isUserInRole(whatever-you-named-the-admin-role)).
If the user is not an administrator, you can use request.getRemoteUser()
to get the user id and then populate the form based on the user's own
data. Here is a similar example:
if ((frm.getDeskPhone() != null)
(request.isUserInRole(Constants.ADMINISTRATOR))) {
rd.setDeskPhone(frm.getDeskPhone());
rd.retrieveByPhone();
} else {
rd.setUid(request.getRemoteUser());
rd.retrieveByUid();
}
...use rd to populate current profile data onto frm...
In this example, the deskPhone parameter is what the admin uses to
loookup a user. The rd object is an entity-like bean that represents a
user.
If you decide to use separate Actions for admins and users --
eliminating the need for the conditional logic above -- you should make
sure NOT to leave the user parameter in the queryString for the
non-administrators or to add a check in the non-admin action to make
sure that the user is editing his/her own profile. In this case, you
should also encapsulate the common elements that both editAccount
actions will share.
Which approach is best depends on the complexity of the application and
how you expect it to evolve over time. The second approach -- different
actions for admins -- is more flexible but a little more work to implement.
hth,
Phil
Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
After reading the suggestions, I am going to go with two different actions for setting up the form. In order to use container managed security most effectively, I am going to prefix paths with admin restrictions with admin/ for ease of filter matching. So /EditAccount /admin/EditAccount?user=username Then I will make a common abstract Action class for editing an account which both actions will extend to make use of the common routines. The /EditAccount will not listen to any query params but rather use the current session data as the data to populate the form with, whereas the /admin/EditAccount will use the user parameter to lookup the user using the DeskPhone as suggested. This way, all the security is controlled by the container, but the logic is left in the action for simply setting it up as instructed (with no checks for security). Thanks for the input and append anywhere I have deviated from the suggestion. Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I am the GOD.the GOD...of house! -- Leeloo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
Dan Allen wrote: After reading the suggestions, I am going to go with two different actions for setting up the form. In order to use container managed security most effectively, I am going to prefix paths with admin restrictions with admin/ for ease of filter matching. So /EditAccount /admin/EditAccount?user=username Then I will make a common abstract Action class for editing an account which both actions will extend to make use of the common routines. The /EditAccount will not listen to any query params but rather use the current session data as the data to populate the form with, whereas the /admin/EditAccount will use the user parameter to lookup the user using the DeskPhone as suggested. This way, all the security is controlled by the container, but the logic is left in the action for simply setting it up as instructed (with no checks for security). Thanks for the input and append anywhere I have deviated from the suggestion. Dan Looks like a good solution to me. I agree that it is best to keep all of the security policies declaratively defined. I also like to keep the link between the logged in user and his/her account automatic (i.e., determined by the system and looked up as close as possible to the model updates) whenever possible. Your solution does both of these things. Note, btw, that I did not mean to recommend desk phone as a generic identifier. Obviously, a) the lookup key best for your admins to use depends on your application and b) whatever you use, it has to be unique. The app that I took the example from enforces this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: case study with security
Looks like a good solution to me. Excellent, I am starting to get this ;) Note, btw, that I did not mean to recommend desk phone as a generic identifier. Naturally, I will use what is specific to my app. Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hey, somebody, sometime, somewhere, said something I think that just maybe might have been true but I think that I maybe didn't like it. F^CK IT, I'm suing everybody. -- slashdot member in response to petswarehouse.com sueing google.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: case study with security
I hope to give my 2 cents here. What I'm going to do (therefore what I would suggest you to do) is to create a custom tag like xSecurity:isUserserName=username / which I'll use in my JSP to present the user some contents instead of some others. The background is that I had to create an application specific User authentication service, based on XML configuration file and commons-digester parsing to validate user's login information with the information contained in the XML configuration file. The process looks like the following: 1) XML user's configuration file: - XML file, containing user's login info, like username, password and role 2) User Service - A Business Service which, given the user's login credentials, returns true if those match the XML configuration file info, otherwise returns false; Login Action - Uses the User Service and if user has the right credentials, CREATE a session attribute with the user details stating that user has the right credentials; Tag library - Retrieves session attribute for user(not the container one, but the application one, from the Form declared in session scope!); if it doesn't exists(meaning that user hasn't logged in succesfully) returns something like SKIP_BODY or EVAL_BODY. I had the need for that because I didn't want to bind, let's say, a Tomcat user with my application user. Now, thinking to put this custom tag at the beginning and at the end of what is crucial to your application it could work fine, in your case: !-- userName here can have the value of 'Administrator' -- xSecurity:isUser userName=userName html:link action=yourAction.do?isAdmin=true / /xSecurity:isUser !-- userName here can have any other value -- xSecurity:isUser userName=userName html:link action=yourAction.do / /xSecurity:isUser Or something similar...I haven't implemented the model yet, so these are only ideas. Regards, Marco -Original Message- From: Dan Allen [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2003 7:04 PM To: Struts-User List Subject: case study with security There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you are going to play the game of trial and error, don't be surprised when the results are revealing. -- me - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: case study with security
It is not necessary to create a specialty tag. If you are using container managed security and your users are set in specific roles you can use the logic:present tag with the role attribute. I do think the right way to do this is have the view conditional based on roles. Mike --- Marco Tedone [EMAIL PROTECTED] wrote: I hope to give my 2 cents here. What I'm going to do (therefore what I would suggest you to do) is to create a custom tag like xSecurity:isUserserName=username / which I'll use in my JSP to present the user some contents instead of some others. The background is that I had to create an application specific User authentication service, based on XML configuration file and commons-digester parsing to validate user's login information with the information contained in the XML configuration file. The process looks like the following: 1) XML user's configuration file: - XML file, containing user's login info, like username, password and role 2) User Service - A Business Service which, given the user's login credentials, returns true if those match the XML configuration file info, otherwise returns false; Login Action - Uses the User Service and if user has the right credentials, CREATE a session attribute with the user details stating that user has the right credentials; Tag library - Retrieves session attribute for user(not the container one, but the application one, from the Form declared in session scope!); if it doesn't exists(meaning that user hasn't logged in succesfully) returns something like SKIP_BODY or EVAL_BODY. I had the need for that because I didn't want to bind, let's say, a Tomcat user with my application user. Now, thinking to put this custom tag at the beginning and at the end of what is crucial to your application it could work fine, in your case: !-- userName here can have the value of 'Administrator' -- xSecurity:isUser userName=userName html:link action=yourAction.do?isAdmin=true / /xSecurity:isUser !-- userName here can have any other value -- xSecurity:isUser userName=userName html:link action=yourAction.do / /xSecurity:isUser Or something similar...I haven't implemented the model yet, so these are only ideas. Regards, Marco -Original Message- From: Dan Allen [mailto:[EMAIL PROTECTED] Sent: Sunday, March 23, 2003 7:04 PM To: Struts-User List Subject: case study with security There have been several discussions on this list about how security should be loosely coupled with the ActionServlet itself (a filter on top of the application), but I am curious to know the best practicing for handling the following type of case. Assume I have an action with a path of /EditAccount. Naturally if a user is not logged in, this path should be protected via filtering. However, /EditAccount has two purposes, one for the regular user to edit his/her own account, but also for the administrator to edit any user account via the query string ?user=username. In this case, I have to check in the action class if the user is allowed to take on the role of another user in which case the form is populated with that user's data or, if not, the form should populate with the user's own data. Is this something that is reasonable to do in the action, or should I create another action path /EditUserAccount?user=username and filter that to only admins and then forward to the /EditAccount once the proper credientials have been established, hence relieving the action behind /EditAccount from looking at any roles? Dan -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Daniel Allen, [EMAIL PROTECTED] http://www.mojavelinux.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you are going to play the game of trial and error, don't be surprised when the results are revealing. -- me - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
