Thanks for the info!
-----Original Message----- From: Max Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 10:16 PM To: Struts Users Mailing List Subject: Re: CMA and LoginAction > Let me get this straight on how it works. > > If I wanted to give out a URL to access my site and I was using CMA then I > could give out http://whatever.com/login.do as the URL and the container > would see that the user is not logged in and through them to the login page > (specified in the web.xml for form based auth) and if that form posted to > j_security_check, if successful auth, then they would be sent to login.do > and in there I would just load up preferences and do whatever and in there > forward to a personalized page etc? As long as /login.do is protected (matches a url pattern that you must be authenticated to view) it will do as you describe. The end of the auth sequence would be a redirect to /login.do. > > But if they tried to access the site with whatever.com/somethingElse.do (and > not currently authenticated) then they would be asked to authenticate > automatically at that point and then sent to somethingElse.do if auth was > successful? Yes, they would go through the authentication sequence and then end up at /somethingElse.do. This is really fantastic from a user experience standpoint. Anyone can bookmark just about any page they want in the site and CMA will do just-in-time authorization. People can email each other URLs, other sites can link to pages in the site, etc. This is a great thing! But, you can't bookmark the login form page, and your app can't do any processing upon authentication. However, a filter could be used to implement nearly equivalent functionality on the processing-at-auth-time front. It would be processing-at-next-request-after-auth in the lingo I've been using here. Here's a simple little filter that will do this (the code is not 100% complete, but it is quite nearly so): public class ProfileFilter implements Filter { public void doFilter(...) { boolean userIsAuthenticated = (request.getUserPrincipal() != null); boolean profileIsPresent = (request.getSession().getAttribute(Profile.SESSION_KEY) != null); if (userIsAuthenticated && !profileIsPresent) { Profile profile = new Profile(request.getUserPrincipal()); request.getSession().setAttribute(Profile.SESSION_KEY, profile); } chain.doFilter(request, response); } } Then declare it in your web.xml and provide an all-inclusive /* mapping to it. Be sure to put its mapping after the SecurityFilter mapping so that request.getUserPrincipal() will work if you are using this with SecurityFilter. The order of the mappings in web.xml determines the order in which the filters will be called when a request matches more than one mapping. This filter will work with CMA also. SecurityFilter addresses the login-page-bookmarkability issue, and we will have some explicit support for the processing-at-authentication-time issue at some point in the future (but no support is there right now). Processing at authentication time is perhaps the most requested feature. Someone emailed me a suggestion for how to support processing at authentication time. Apparently the Resin container has an interface/class that you can implement/extend and then register with the container to have your processing method called when someone authenticates. This method is called with a reference to the session so that you could put profile info in there, etc. This is a cool idea. I don't know any other containers that have such a thing. It would be great if something like this made it into the Servlet spec. The other alternative that I was considering is that you could register a URI for a resource that would do the processing. SecurityFilter would authenticate the user, and then forward to the specified resource for additional processing. The request would be forwarded with a wrapped (or entriely new) response that would ignore (think > /dev/null) anything that was written or changed in the response. SecurityFilter would regain control after the processing finishes, and it would redirect the user to the default page or wherever it was that they were going. This is nice because we don't have to define any new interfaces (yeah!), but the part where it ignores the response is rather confusing (boo!). I am leaning toward the Resin-style solution for this. If anyone has opinions on how this should be done, I would love to hear them. Pro/con comments about the solutions described above, or completely new ideas are welcome. > > So now if you could only direct me to a reference for getting CMA to work > with JRun and Objectivity (I've read the docs out there and I must be > missing a small detail for implementing custom login and I have no support > contract from JRun). The login module stuff isn't hard it is configuring > the custom User Manager that is so poorly documented. I wish I could help, but I am not familiar with JRun/Objectivity CMA configuration. -Max > > TIA > > > > -----Original Message----- > From: Max Cooper [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 6:44 PM > To: Struts Users Mailing List > Subject: Re: CMA and LoginAction > > CMA does just-in-time authentication. You will only be authenticated on the > way to viewing a protected resource. After your authentication succeeds, you > will end up at the protected resource that you originally requested. This is > very nice because logging in doesn't take the user off the course of what > they were trying to achieve. > > But, it also means that you can't have users login at will, or issue an > "unsolicited" login request by randomly posting to j_security_check. > Actually, you can support this a bit by having the "Login" link take you to > a protected resource, which will force the CMA to do the authentication > routine along the way. Your protected resource might just redirect you back > to the home page or something if that is what you want. You can't have a > login form on every page, though, because the container won't know where to > send them after they are logged in. This limitation also creates problems if > users bookmark the login form page. > > This is one of the reasons I started the Security Filter project. It allows > "unsolicited" login requests, and you can configure where users should be > sent if they issue an "unsolicited" login request. It also supports > just-in-time authentication like CMA, which is how it will work if Security > Filter initates the authentication sequence in response to a request for a > protected resource. > http://securityfilter.sourceforge.net/ > > -Max > looking for lots of securityfilter hits today ;-) > > > ----- Original Message ----- > From: "Bailey, Shane C." <[EMAIL PROTECTED]> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > Sent: Friday, June 06, 2003 7:28 AM > Subject: RE: CMA and LoginAction > > > > > > This makes me think of another question. I have put implementing my CMA > on > > hold but I will need to know this soon: > > > > If you specify where to go prior to the CMA j_security_check call (by > > describing the login form in the web.xml) why don't you have to describe > the > > "success" page (most likely an action) to go to as well? So where does a > > successful CMA auth take you? > > > > I am guessing it goes to the welcome page also described in the web.xml? > > > > Anyway, if that is the case can you have your welcome page be > > "userInitialize.do" ??? That would work right? > > > > > > BTW, we started using Objectivity and JRun has LoginModules provided for > > LDAP,Relational and XML storage and not oodb. I tried to write a custom > > LoginModule (not really a problem) and a customer User manager class and > it > > hasn't worked. Anyone successful in such things? > > > > > > > > -----Original Message----- > > From: Mohan Radhakrishnan [mailto:[EMAIL PROTECTED] > > Sent: Friday, June 06, 2003 10:15 AM > > To: 'Struts Users Mailing List' > > Subject: CMA and LoginAction > > > > Hi > > > > I would like to use role based authentication. That is CMA. Now I > > also want to call my Action class. The idea is to use > > > > <logic:present role="name"/> > > > > My Action class sets up user profiles based on the login ID etc. Is this > > possible ? > > > > Mohan > > > > > > > > --------------------------------------------------------------------- > > 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]