Hi Max, this sounds interesting, I don't want to miss this when you release it, be sure to let us know or setup a web page.
What are you using as a data store for principals and permissions to develop/test your application? DB, LDAP, ? Are there dependencies on a particular version of JDK in your implementation? A reminder that not all containers support the 2.3 spec, so some older servers in production wouldn't support them. Such as my weblogic 6.0. :-( -d- -----Original Message----- From: Max Cooper [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 31, 2002 12:52 AM To: Struts Users Mailing List Subject: Re: Security and Struts Ryan, I have written just such a filter and I plan to release it in the next week or two. It will be free to use and will include source code if you want to modify it. It mimics container-managed security (which I also like for various reasons). It wraps the request to give proper responses to all the security methods like getRemoteUser(), isUserInRole(), and getUserPrincipal(). You can write your app to use container-managed security and switch to/from the filter without any changes. The only exception is the realm implementation. The realm interface for my filter is very simple [two methods -- authenticate(username, password) and isUserInRole(username, rolename)] so it is easy to implement or adapt to/from an existing realm interface. That makes it portable across different servers, but the realm implementation will be tied to the filter by the filter's proprietary realm interface. Some of the big advantages to using a filter are that you can deploy your whole app (including the realm implementation) as a web app, and it will be portable across different app servers. If you use container-managed security, you need to configure your realm at the server level and put it into the server's classpath. For a project that I have been working on, that drags a whole lot of persistence layer code out of the application and into the server's classpath. I didn't like that and it created deployment and server migration problems, so I wrote a filter. That filter has been in production for more than 6 months with no open issues. Another thing that I don't like about container-managed security is that the realm implementation is specific to the server you deploy on (though JAAS is supposed to fix this, it seems complicated on first glance). The filter is intended to mimic container-managed security as much as possible, but I also implemented an extension that is quite useful to have. With the filter, you can login without having been forced to the login form by making a request for a secured page. This allows you to put a login form on every page (which is quite difficult to do well with container-managed security). You can also have a link to the login form on every page, which you can still do with container-managed security, but requires a little work-around work. I am working hard to get it release-ready, and I will post a message to this list when it is available. It is not trivial to write a filter that handles all the various issues you run into properly (saving POSTed parameters, working around bugs in the RequestWrapper implementations, etc.) so it might be worth a little wait for my filter if you are thinking of going that route. In the mean time, you might go ahead with container-managed security and make the switch when the filter is available, as the app will work without changes and you will even be able to cut your security configuration out of web.xml and paste it into the filter config file with some additional info during the migration. My first goal is to provide all the functionality of container-managed security, but I have also been thinking about extending it to allow you to plug in user-written modules to provide security based on query string parameters, etc. It is often best to write programmatic security for such things [?id=10 or ?id=20 on top of the container security -- getRemoteUser(), isUserInRole()] in your Actions to minimize database calls. But query string based programmatic security modules might be useful for things where no db access is required (doSomething.do?mode=view versus doSomething.do?mode=edit) or perhaps where the items loaded from the database can be made available to the Action (i.e. stuff them in the request scope, if you don't find the security-plugin/Action dependency too objectionable). I am not yet sure how useful this stuff will be or what the implementation details will be, and it won't be available with the filter right away. -Max ----- Original Message ----- From: "Ryan Cuprak" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, July 30, 2002 6:58 PM Subject: Re: Security and Struts > > Hello, > > I have been looking into using a filter Servlet (implementing Filter > interface) to screen incoming requests however in Sun's api, the doFilter > receives a ServletRequest and not a HttpServletRequest. The > HttpServletRequest of course has the getSession where I can retrieve (if it > exists) the login information previously stored there. I did some > introspection and discovered in tomcat that the ServletRequest object that > is returned is of type 'HttpServletRequest' but am unsure if this is a safe > assumption to make. The documentation on the Sun site stated that the filter > interface could be used for authentication but if one does not have access > to the session information I don't see how. > The reason I am not using container authentication or the built-in role > capabilities is because my setup is much more complicated and needs to be > stored in a relational database (there are desktop apps which also will key > off this information etc.) > > -Ryan > > On 7/30/02 3:33 PM, "Joe Barefoot" <[EMAIL PROTECTED]> wrote: > > > > > A third option is to use a ServletFilter to do the same. This has the > > advantage of sitting outside of the Struts framework, so you can enforce > > security on other (non-Struts) Servlets and resources if you have them. > > Check out the Servlet 2.3 API and tech. articles for info on ServletFilters. > > You would have to come up with your own declarative role-resource mapping > > configuration in this case, but that is not too difficult. Just use an XML > > file that maps URLs to allowed role names. > > > > Finally, Container-managed authentication/authorization is okay, but it is > > application-server specific and would have to be modified for any port to > > another container. > > > > > > peace, > > Joe > > > > -----Original Message----- > > From: Ryan Cuprak [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, July 30, 2002 11:53 AM > > To: [EMAIL PROTECTED] > > Subject: Security and Struts > > > > > > > > Hello, > > I was hoping someone would have some advice on securing a website using > > struts. I am developing a webapp that has to be secure (password protected) > > and which restricts access to different parts of the site depending on the > > roles a user possesses. The roles each user has are stored as XML in a > > database and may be configured by an administrator. Does struts have any > > built-in security capabilities that I could take advantage of? > > > > > > Any help/pointers would be much appreciated! > > > > My first guess would be to put all jsp pages in WEB-INF (use only > > ForwardAction to get to each page) and subclass ActionServlet with the logic > > for check authentication etc. However, will this cause any problems when it > > comes to a user book marking a page? > > > > Thanks, > > -Ryan Cuprak > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
