You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jason Lea <ja...@kumachan.net.nz> on 2003/06/26 23:55:43 UTC
Re: [OT] SecurityFilter Question was RE: Looking for ideas for actio
n servlet checking for logged in user.
Hi Shane,
Looks fine to me :)
I also had a similar thought in the beginning to create my own Principal
object so I could store all sorts of app specific info when the user
authenticates. It seemed to make sense until I started trying to write
my own. There are also some disadvantages as you can't easily switch
realms eg switch to use Tomcat's JNDI Realm instead of JDBC Realm. In
each case I would have to write my own implementation so MyPrincipal
object was returned.
In the end it was a lot of work and I came up with a better solution:
I use the standard Tomcat JDBC/JNDI Realms for authentication, so this
is very portable. Then your application just has to figure out when a
user has logged in for the first time.
When user authenticates use a filter or have all of your actions extend
a BaseAction that checks for the login and puts the extra info into a
User object and store that in a session scope.
The standard realm only accesses the database when you authenticate and
it collects the list of roles and populates the GenericPrincipal. So it
is quite efficient in that manner.
I hope this will be portable across web containers - I just have to plug
in a new Realm from the other container.
--jason
Bailey, Shane C. wrote:
>
> So I am real close to moving to the securityfilter (I've been reading the
> docs, etc.) a question I have then is in order to implement the
> SecurityRealmInterface.isUserInRole(Principal principal, String rolename);
> method I would like to not go to the DB (inside the method) everytime it is
> called so is this so bad to do:
>
>
> class MySecurityRealm extends SecurityRealmInterface
> {
> public boolean isUserInRole(Principal principal, String rolename)
> {
> //Since java.security.Principal doesn't have the methods I want...
> MyPrincipal p = (MyPrincipal)principal;
>
> //This next method is only in MyPrincipal and not Principal
> interface
> List roles = p.getRoles();
>
> //do the role test here
>
> //return true or false here
> }
>
>
> public Principal authenticate(String username, String password)
> {
> //Do username and password test
>
> if(successful)
> {
> MyPrincipal p = new MyPrincipal();
> p.setName(username);
> //Get list of roles for the user from DB
> p.addRoles(...);
>
> return p;
> }
>
> return null;
> }
>
>
> }
>
>
>
>
>
> -----Original Message-----
> From: Jason Lea [mailto:jason@kumachan.net.nz]
> Sent: Thursday, June 26, 2003 5:34 AM
> To: Struts Users Mailing List
> Subject: Re: Looking for ideas for action servlet checking for logged in
> user.
>
> In case no one has mentioned it yet:
>
> http://securityfilter.sourceforge.net/
>
> This emulates the container managed security but uses filters.
> You can define the security contraints in security-filter.xml (looks
> similar in structure to web.xml) eg
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>Administrator-only Area</web-resource-name>
> <url-pattern>/admin/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>admin</role-name>
> </auth-constraint>
> </security-constraint>
>
> You can even use the Tomcat's JDBC Realm with it. This means you can
> use the request.isUserInRole() and you can define access to Struts
> actions by role eg:
>
> <action
> path="/admin/Admin"
> type="org.apache.struts.actions.ForwardAction"
> parameter=".main.admin"
> roles="admin,someOtherRole,yetAnotherRole">
> </action>
>
> Or display tiles if they have the right role eg
>
> <definition name=".secrets.tile" path="/WEB-INF/jsp/tiles/secrets.jsp"
> role="admin" />
>
> The other problem you normally encounter is creating a few objects that
> you want in your session after a user logs in eg get user's name, email,
> phone number etc throw it into a User object and store it in the session
> so you can refer to it later.
>
> There are a couple of choices...
>
> 1. Create a BaseAction class that all of your other Actions extend
> 2. Use a Filter
>
> The process is the same for each:
>
> a. Check to see if request.getUserPrincipal() is not null. If null, the
> user has not been authenticated
>
> b. If the user has been authenticated check to see if you have defined a
> session variable eg session.getAttribute("USER_LOGGED_IN")
>
> c. If it hasn't been defined, then this is a newly logged in user and
> you can do your initialisation stuff, record the login etc and store
> something in our session variable session.setAttribute("USER_LOGGED_IN",
> Obj)
>
>
> If you want to log the user out you can use session.invalidate()
>
> --jason
>
>
> Adam Hardy wrote:
>
>>The drawback to using filters compared to security constraints is that
>>you would have to roll your own login mechanism - which seems
>>unnecessary when you could use the container's authentication method.
>>
>>Did you mention having to change Tomcat to get it to use your JDBC
>>realm? I'm not sure quite what you mean, but yes I suppose if you have a
>>complex realm module and you're not going to use container-managed
>>security, I guess filters or constraints would be just as good.
>>
>>
>>Adam
>>
>>Michael Remijan wrote:
>>
>>
>>>Filters have mapping patterns just like servlets have mapping patters
>>>(take a look at the web.xml DTD). So like you say servlet "Foo" is
>>>mapped to *.foo or /foo/* you can map a filter to urls as well. So if
>>>you have a directory in your webapp named "secure". can protect all
>>>the jsp pages in that directory with the mapping /secure/*.
>>>similarly, you can add the mappings of servlets to protect them in the
>>>same way.
>>>
>>>Michael.
>>>
>>>-----Original Message-----
>>>From: Jing Zhou [mailto:jing@netspread.com]
>>>Sent: Wednesday, June 25, 2003 11:54 AM
>>>To: Struts Users Mailing List
>>>Subject: Re: Looking for ideas for action servlet checking for logged in
>>>user.
>>>
>>>
>>>This is an interesting use of Filters. Our action mappings have
>>>an attribute, 'privileged'. When the privileged attribute is set to true,
>>>users only with a true privileged mode in his/her action
>>>tracking (in the user's session) can execute the corresponding actions.
>>>
>>>Can a filter be easily bound to the dynamic security requirements
>>>as shown above? and in what ways, any ideas?
>>>
>>>Jing
>>>
>>>----- Original Message ----- From: "Michael Remijan"
>>><Mi...@solocup.com>
>>>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>>Sent: Wednesday, June 25, 2003 10:49 AM
>>>Subject: RE: Looking for ideas for action servlet checking for logged in
>>>user.
>>>
>>>
>>>I've found using security constraints to be a little cumbersome,
>>>especially
>>>since it requires some moderate modification of tomcat to put in a jdbc
>>>realm that fits your needs.
>>>
>>>My preference is to use Filters. A filter set up on your secure
>>>directory
>>>(specifed as /secure-dir-name/*) can be run, check for an object in the
>>>session, and easily redirect if not found.
>>>
>>>Mike
>>>
>>>-----Original Message-----
>>>From: Jing Zhou [mailto:jing@netspread.com]
>>>Sent: Wednesday, June 25, 2003 10:10 AM
>>>To: Struts Users Mailing List
>>>Subject: Re: Looking for ideas for action servlet checking for logged in
>>>user.
>>>
>>>
>>>
>>>----- Original Message ----- From: "Adam Hardy"
>>><ah...@cyberspaceroad.com>
>>>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>>>Sent: Wednesday, June 25, 2003 4:13 AM
>>>Subject: Re: Looking for ideas for action servlet checking for logged in
>>>user.
>>>
>>>
>>>
>>>
>>>>I would use container-managed security. All the secured pages should go
>>>>in a directory which is the target of a security constraint in the
>>>>deployment descriptor. This forces the user to log in when trying to
>>>>access any secured pages. In the actions where a user-object is
>>>>required, this can be retrieved on demand using the user-name from the
>>>>login, and then stored in the session.
>>>
>>>
>>>
>>>What I am doing is, yes, everything is under security constraints and
>>>when
>>>the user logins, an action tracking object is created to maintain the
>>>user
>>>related objects. The action tracking is stored in the user's session.
>>>When
>>>the user logout, the action tracking is cleared and removed from the
>>>user's session. The action tracking has a lot other responsibilities.
>>>
>>>
>>>
>>>>hth
>>>>Adam
>>>>
>>>
>>>
>>>Jing
>>>
>>>
>>>
>>>>Jing Zhou wrote:
>>>>
>>>>
>>>>>----- Original Message ----- From: "Larry Zappeterrini"
>>>>><La...@SanchezProjects.com>
>>>>>To: "'Struts Users Mailing List'" <st...@jakarta.apache.org>
>>>>>Sent: Tuesday, June 24, 2003 4:13 PM
>>>>>Subject: RE: Looking for ideas for action servlet checking for
>>>>>logged in
>>>>>user.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Check out http://marc.theaimsgroup.com/?t=104454850300003&r=1&w=2
>>>>>>for a
>>>>>>possible solution.
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: henrik.bentel@teradyne.com [mailto:henrik.bentel@teradyne.com]
>>>>>>Sent: Tuesday, June 24, 2003 4:59 PM
>>>>>>To: struts-user@jakarta.apache.org
>>>>>>Subject: Looking for ideas for action servlet checking for logged in
>>>>>>user.
>>>>>>
>>>>>>
>>>>>>I have a webapp which have several pages which require the user to be
>>>>>>logged in(have a httpSession with a "usercontainer" object stored)
>>>>>>, and
>>>
>>>
>>>a
>>>
>>>
>>>>>>few pages that doesn't require a log in(the log-in page, references,
>>>>>>indexes...). All pages are fronted by actions.
>>>>>>My current solution is to check for valid login in every action class
>>>
>>>
>>>that
>>>
>>>
>>>>>>needs to protect its invocation. That seems tedious. I though about
>>>>>>extending the action servlet to do it, but then it would check for all
>>>>>>requests.
>>>>>>And I do want to distinguish between if the user is
>>>>>>authorized(isUSerInRole) and if he/she is even logged in, so I
>>>>>>can't use
>>>>>>the role parameter in the action element.
>>>>>>
>>>>>>My next idea is extending the action servlet pluss adding parameters
>>>
>>>
>>>that
>>>
>>>
>>>>>>can go into the action element in the struts-config.xml file.
>>>>>>(some thing like <action path="/doImportantAction"
>>>>>>type="my.actionClass"
>>>>>>usersession="true"> )
>>>>>>This would require my action servlet to know about my userContainer
>>>
>>>
>>>stored
>>>
>>>
>>>>>>in the httpsession. Pluss modifying the struts-config file.
>>>>>>I haven't looked into how hard this is, figure I'd ask someone
>>>>>>who's run
>>>>>>into this before.
>>>>>>
>>>>>>Any other good approaches, or should I just stick with what I
>>>>>>got?(check
>>>>>>individually in every action)
>>>>>
>>>>>
>>>>>
>>>>>Yes. So far so good. One possible improvement is that you put all of
>>>>>the checking codes into a base class of your action classes. Then you
>>>>>extend the action mapping to provide additional attributes that allow
>>>>>the checking codes to configure themselves dynamically for the
>>>>>corresponding actions, e.g. the usersession attribute.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>thanks,
>>>>>>Henrik Bentel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>Jing
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
> ***************************************************************************
>
>>>
>>>>>>This electronic mail transmission contains confidential and/or
>>>
>>>
>>>privileged
>>>
>>>
>>>>>>information intended only for the person(s) named. Any use,
>>>
>>>
>>>distribution,
>>>
>>>
>>>>>>copying or disclosure by another person is strictly prohibited.
>>>>>>
>>>>>
>>>>>
> ***************************************************************************
>
>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>
>
>
--
Jason Lea
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org