thanks for your input. I will evaluate it tomorrow morning. By the way, what do you think of the idea of having a web-server in front of an app-server for login purposes. Isn't that unnecessary. I am sure our current architecture is because the way things evolved for this 5-6 year old webapp. But I think I can also consider just taking out the webserver and letting weblogic app server handle the initial login and use some security filter (may be acegi or regular custom written filters) to make sure the user is still entitled to access any specific resources. We can still have the webserver for the static content, but login piece should get moved entirely to the app-server. what do you think ??? thanks again for any helpful pointers in advance, robin
Frank W. Zammetti wrote: > > All of our security is LDAP-based, but we simply use the built-in > mechanisms that Websphere provides... you can easily tell it, in > conjunction with plain old J2EE security, to validate users against > LDAP. This works very similar to the steps you outline. > > Now, on top of that we've build our own security framework to handle the > things that J2EE security and/or Websphere doesn't, things like > cross-site scripting, password policy adherence, extended timeout > capabilities, and so forth. > > The other nice thing about it is that we essentially get single sign-on > for free... the LPTA token that is used can be used across applications, > so long as Websphere is configured properly (has to do with being in the > same cell, or making cells aware of each others' tokens, details I'm > frankly not as familiar with). Note that this is different than the > session cookie your familiar with... it's a token created by Websphere > when a user has been authenticated. > > In your shoes, I think my gut reaction would be to explore using J2EE > security with whatever container your going to use, see how far you can > get with just that. I suspect you can get most of the way... then see > if you can fill the gaps with simple filters and such... obviously you > don't want to take that exercise too far though or your just inventing > things that already exist somewhere, but if its not a huge amount it > might be worth it (and you may find you don't need to do anything at all > beyond the standard stuff). > > HTH, > Frank > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > AIM/Yahoo: fzammetti > MSN: [EMAIL PROTECTED] > Author of "Practical Ajax Projects With Java Technology" > (2006, Apress, ISBN 1-59059-695-1) > and "JavaScript, DOM Scripting and Ajax Projects" > (2007, Apress, ISBN 1-59059-816-4) > Java Web Parts - http://javawebparts.sourceforge.net > Supplying the wheel, so you don't have to reinvent it! > > robinbajaj wrote: >> Hi All, >> I am working on a production web application written in Struts 1.2.x . >> Recently we undertook an effort to redesign our login architecture. >> Currently our architecture is that >> 1) user is presented with a login page served by IIS server (ASP pages) >> 2) user's provided username/password is validated against LDAP server, >> and a >> token is returned. That token is stored in the database as well. >> 3) That security token is put in the session scope and then the control >> is >> passed on the weblogic server, where the security token from the session >> is >> compared with the one stored in the database to verify its the same user >> who >> logged in at step (1). >> 4) the struts web flows are selected and user selects and runs through >> the >> appropriate web flows. >> >> I am working on redesigning this login scheme. The IIS is only there >> since >> the login front-end was originally designed in ASP and either way its a >> good >> practice to have a web server to serve the static pages and an app server >> for dynamic content. (we don't mind replacing IIS with Apache tomcat >> etc..if >> we have to..) >> I am looking for any suggestions that any experienced web developers have >> implemented to implement a login scheme (*using LDAP repositories). >> I recently evaluated Spring's ACEGI framework and found it to be pretty >> promising. I am not sure, if >> there's anything else that I should/can consider. >> Moreover, my question for this forum is whether the above architecture is >> a >> good one or is there some scope of improvement in it, that we can >> implement >> using ACEGI framework .... or some other login/security framework that >> you >> folks can suggest... >> thanks a lot for any input in advance, >> robbby > > -- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/suggestions-for-login-scheme-using-struts-1.x-tf3912491.html#a11092918 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
