RE: Security, authentication and authorisation with Struts
We actually do more or less the same. During the login phase we retrieve the user profile which includes the authorization information and store this in the session context. Each action can then take some access control decision based on this information. However I am currently trying to use JAAS (Java Authentication and Authorization Service) just for the authorization part. I have written a doc on the various issues of doing so and how I'm planning to do so. I'm still working on it but it may be useful to some of you, so I attach it. This document mentions eShell: this is the name of the framework we use, and it is extending Struts. As usual, any comments on this is welcome :) Fr. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 24 August 2001 15:27 To: [EMAIL PROTECTED] Subject: RE: Security, authentication and authorisation with Struts I wondered what approach you guys took when implementing security, authentication and authorisation. I have the common scenario where the application I am creating allocates roles to certain types of users, allows them to login, then restricts access to certain pages and within the pages certain content. I use a subclass of ActionServlet that ensures that the username (a String) and authorization info (a bean) for this user are saved in the session scope before any Actions are called. (They aren't combined into one object because I need the username for other situations when I may not require auth information.) At the top of each Action I consult the authorization bean to see if this user has the appropriate permissions to call this Action. If so, I just keep going. If not, I forward to a JSP that tells them no. If the authorization bean doesn't exist anymore it's because the session timed out in which case I forward to another JSP asking them to start over. The ability to choose your view in the Action is really, really nice. I don't have a login procedure because there is a front-end that they need to pass through before they get to my application and this guarentees me a username in the HTTP headers. So I just need to pull it out of the headers in the special ActionServlet subclass and put it in the scope. But it would be easy enough for a login page to do the same thing. Devon The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *** Title: Using JAAS within eShell web applications Using JAAS within eShell web applications [Introduction] [JAAS support in eShell] [Configuration] Introduction The Java Authentication and Authorization Service (JAAS) is a standard Java API that extends the standard Java security model in order to: Provide a standard API of authenticating users while allowing different authentication methods to be plugged-in (pluggable login modules). Provide subject-based access control by extending the standard Java 2 security model: access control can be based on who is running the code in addition to which code source is running. Allow the use of a custom policy object which can retrieve user permissions from any storage. JAAS is distributed as a standard extension to the J2SE 1.3 platform, and is completely integrated into J2SE 1.4. However despite this integration, there are important issues that makes it difficult to integrate JAAS in the context of a web application. Integration Issues The issues one faces when using JAAS within a web application relate on one side to the current state of the J2EE specifications, and on the other side to the way JAAS is currently defined. At present there is no way to provide a portable solutions to these issues. Issues with the J2EE specification The issues with the current J2EE 1.2 specification is that it does not integrate JAAS. Indeed, container providers are not required to use JAAS for implementing authentication and authorization. In the case of the Servlet specification, web containers are just required to support: Basic authentication: browser asks for userid/password Form-based authentication: allow a custom screen for userid/pwd Client certificate authentication: based on PKI infrastructure Role-based access control to web resource Therefore it's only through these standard authentication and authorization mechanisms that one can benefit from container managed security (e.g. propagation of the user identity to an EJB container). The J2EE specification v1.3 goes a little further in integrating JAAS within the J2EE
Re: Security, authentication and authorisation with Struts
rey-- that seems like a reasonable approach, but i've read in more than one post on this board that subclassing the ActionServlet should be avoided. wouldn't it be better to put this code directly into the action servlet and rebuild struts? i'd also be interested in hearing the rationale behind the desire not to subclass ActionServlet from those of you who prefer to avoid it. jon Rey Francois wrote: We actually do more or less the same. During the login phase we retrieve the user profile which includes the authorization information and store this in the session context. Each action can then take some access control decision based on this information. However I am currently trying to use JAAS (Java Authentication and Authorization Service) just for the authorization part. I have written a doc on the various issues of doing so and how I'm planning to do so. I'm still working on it but it may be useful to some of you, so I attach it. This document mentions eShell: this is the name of the framework we use, and it is extending Struts. As usual, any comments on this is welcome :) Fr. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 24 August 2001 15:27 To: [EMAIL PROTECTED] Subject: RE: Security, authentication and authorisation with Struts I wondered what approach you guys took when implementing security, authentication and authorisation. I have the common scenario where the application I am creating allocates roles to certain types of users, allows them to login, then restricts access to certain pages and within the pages certain content. I use a subclass of ActionServlet that ensures that the username (a String) and authorization info (a bean) for this user are saved in the session scope before any Actions are called. (They aren't combined into one object because I need the username for other situations when I may not require auth information.) At the top of each Action I consult the authorization bean to see if this user has the appropriate permissions to call this Action. If so, I just keep going. If not, I forward to a JSP that tells them no. If the authorization bean doesn't exist anymore it's because the session timed out in which case I forward to another JSP asking them to start over. The ability to choose your view in the Action is really, really nice. I don't have a login procedure because there is a front-end that they need to pass through before they get to my application and this guarentees me a username in the HTTP headers. So I just need to pull it out of the headers in the special ActionServlet subclass and put it in the scope. But it would be easy enough for a login page to do the same thing. Devon The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *** Name: JAAS and eShell.html JAAS and eShell.htmlType: Hypertext Markup Language (text/html) Encoding: quoted-printable
RE: Security, authentication and authorisation with Struts
I would highly recommend looking at JAAS for authentication/authorization. I'm using it in conjunction with Struts right now (using JBoss/Tomcat) and everything is working fine. I'm still in development and haven't gone live yet, but so far so good. JAAS takes a little while to get your head around. Lots of terminology to decipher. But the promise of implementation independent security in your application was worth it for me. It's pretty straight forward in JBoss, but again it'll take you some time reading and playing with it before it starts making sense. See http://java.sun.com/products/jaas/index-10.html for more details. -ryan -Original Message- From: Prior, Simon To: '[EMAIL PROTECTED]' Sent: 8/24/2001 8:11 AM Subject: Security, authentication and authorisation with Struts Hi Guys, I wondered what approach you guys took when implementing security, authentication and authorisation. I have the common scenario where the application I am creating allocates roles to certain types of users, allows them to login, then restricts access to certain pages and within the pages certain content. As this is a very common problem/scenario I wondered what approach you guys took when using Struts. Do you utilise container managed security or do you use application managed security? - what have you found works best with Struts? Does anyone have any suggestions or example applications I could take a look at? Thanks in advance, Simon. For optimum solutions that save you time, visit www.ds-s.com.
Re: Security, authentication and authorisation with Struts
Jonathan M Crater wrote: i'd also be interested in hearing the rationale behind the desire not to subclass ActionServlet from those of you who prefer to avoid it. Offering alternatives to subclassing ActionServlet so that other resources (like things for ValidatorForm and Tiles) can be loaded has come up a lot, and Oleg has come up with a good solution that we are testing. So, the context here is why should I subclass the ActionServlet *just* to do this. And if we all start offering cool resources that require the ActionServlet to be subclassed, the heirarchy can get out of control. But, I don't believe there are systemic problems with sublassing ActionServlet for appliation-specific needs. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/
RE: Re: Security, authentication and authorisation with Struts
wouldn't it be better to put this code directly into the action servlet and rebuild struts? That goes against my code-reusability instincts. I strive to use the default struts build and default tag libraries. The other possibility would be to put this in the Action class. Before it checks the authorization, it could verify that it is in the session. If not, put it there. I don't do this because I also put an object in the application scope (for complicated reasons) and it seems silly to put this code in the Action code which is rather far from the application level. i'd also be interested in hearing the rationale behind the desire not to subclass ActionServlet from those of you who prefer to avoid it. Me too. Works fine for me. Devon
Re: Security, authentication and authorisation with Struts
i would prefer not to put the authentication code in the action because it opens the possibility of having authentication logic in each and every action, which would essentially defeat one of the main purposes of having a controller in the first place--one point of access for security reasons. it seems to me that subclassing ActionServlet and/or adding authentication code to it are preferable to distributing the authentication logic across x number of action classes. [EMAIL PROTECTED] wrote: wouldn't it be better to put this code directly into the action servlet and rebuild struts? That goes against my code-reusability instincts. I strive to use the default struts build and default tag libraries. The other possibility would be to put this in the Action class. Before it checks the authorization, it could verify that it is in the session. If not, put it there. I don't do this because I also put an object in the application scope (for complicated reasons) and it seems silly to put this code in the Action code which is rather far from the application level. i'd also be interested in hearing the rationale behind the desire not to subclass ActionServlet from those of you who prefer to avoid it. Me too. Works fine for me. Devon
Re: Security, authentication and authorisation with Struts
I would agree that subclassing the ActionServlet is usually preferable, but would point out that the strategy is to provide a BASE action with the authentication code, that others would subclass. So the authentication code would only exist once, in the base class. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ Jonathan M Crater wrote: i would prefer not to put the authentication code in the action because it opens the possibility of having authentication logic in each and every action, which would essentially defeat one of the main purposes of having a controller in the first place--one point of access for security reasons. it seems to me that subclassing ActionServlet and/or adding authentication code to it are preferable to distributing the authentication logic across x number of action classes. [EMAIL PROTECTED] wrote: wouldn't it be better to put this code directly into the action servlet and rebuild struts? That goes against my code-reusability instincts. I strive to use the default struts build and default tag libraries. The other possibility would be to put this in the Action class. Before it checks the authorization, it could verify that it is in the session. If not, put it there. I don't do this because I also put an object in the application scope (for complicated reasons) and it seems silly to put this code in the Action code which is rather far from the application level. i'd also be interested in hearing the rationale behind the desire not to subclass ActionServlet from those of you who prefer to avoid it. Me too. Works fine for me. Devon
RE: Re: Security, authentication and authorisation with Struts
i would prefer not to put the authentication code in the action because it opens the possibility of having authentication logic in each and every action In my case, each action needs a different authentication. For example, some users have read-only access and some have modify access. Devon
Re: Security, authentication and authorisation with Struts
Have you looked at Nic's extensions for Role-Based Actions? http://husted.com/about/struts/struts-security.htm [EMAIL PROTECTED] wrote: i would prefer not to put the authentication code in the action because it opens the possibility of having authentication logic in each and every action In my case, each action needs a different authentication. For example, some users have read-only access and some have modify access. Devon -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/
RE: Security, authentication and authorisation with Struts
Jonathan: Another approach you may want to look at is the way we've done the Struts integration with our own OSS framework, Expresso: We subclass Action in our Controller class, and the Controller class actually does all of the authentication/authorization work for us. There of course more to it than that, but that's the gist - you can read about it at http://www.jcorporate.com/doc/index.html - the Expresso Developer's Guide explains about our Controller objects (basically finite-state machines that contain the application's logic) and there are a couple of write-ups in the index about how Struts and Expresso fit together. We have optional strong encryption for Expresso's entire security layer (and it's object/relational mapping layer), which is also discussed in the doc, making it possible to implement a highly secure application at all levels. Hope it's helpful! Regards, Mike Jcorporate Ltd. http://www.jcorporate.com -Original Message- From: Jonathan M Crater [mailto:[EMAIL PROTECTED]] Sent: Friday, August 24, 2001 10:45 AM To: [EMAIL PROTECTED] Subject: Re: Security, authentication and authorisation with Struts i would prefer not to put the authentication code in the action because it opens the possibility of having authentication logic in each and every action, which would essentially defeat one of the main purposes of having a controller in the first place--one point of access for security reasons. it seems to me that subclassing ActionServlet and/or adding authentication code to it are preferable to distributing the authentication logic across x number of action classes. [EMAIL PROTECTED] wrote: wouldn't it be better to put this code directly into the action servlet and rebuild struts? That goes against my code-reusability instincts. I strive to use the default struts build and default tag libraries. The other possibility would be to put this in the Action class. Before it checks the authorization, it could verify that it is in the session. If not, put it there. I don't do this because I also put an object in the application scope (for complicated reasons) and it seems silly to put this code in the Action code which is rather far from the application level. i'd also be interested in hearing the rationale behind the desire not to subclass ActionServlet from those of you who prefer to avoid it. Me too. Works fine for me. Devon
