Not sure if I undestand your question (so I will make some random statements and see if one hits the spot :) )
I guess reading this would help: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html
But basically, you might decide to store your usernames/passwords/roles in a database separate from your application datastore. In this case you will have one connection to your application datastore and the JDBC realm will have a different connection to a different database.
Of course they might be in the same database. Or you might have your username/passwords/roles list stored in an LDAP server (using the JNDI realm to access it). Tomcat can also store them in an XML file (Memory realm). You might come across a situation where these usernames/passwords/roles are provided by some other source in which case you can write your own Realm implementation to access it.
This doesn't mean each user has to log into the database under their own username/password (though you could if you want).
In my situation my application has a username/password that connects to the database. When a user makes a request of one of my Struts Actions I can check their role to see if I will perform the operation on the database. The changes are still made under my application's database connection.
Hope this answers your question...
--jason
Bailey, Shane C. wrote:
Thanks for the response.
For my lack of knowledge, I understand the concept of realm but why is there a separate JDBC realm? Is this so you can have each user have a login to the database (essentially) instead of everyone using the same DB login to do datastore transactions?
-----Original Message-----
From: Jason Lea [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 5:56 PM
To: Struts Users Mailing List
Subject: Re: [OT] SecurityFilter Question was RE: Looking for ideas for
action 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 4:59 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
***************************************************************************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: [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]
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
-- Jason Lea
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
