thanks for your input Frank. When I mentioned about taking out the webserver, I only meant not to have it do the login. It can still serve the static content. But I suggested merging the login piece and the actual web-app, and running them both on the weblogic app server. what I don't understand is then why do I hear people (including you) mention that their webserver is in front of their appserver. What kind of functionality does a webserver provide by being in "front" of the app server. I mean, having it for serving the static content does not put it architecturally in "front" of the app server. Please help me understand, robin
Frank W. Zammetti wrote: > > We have web servers in front of the app servers, and this isn't an > evolution of old apps, I'm talking newly developed apps. There's nothing > unusual about that setup at all, it's pretty typical in an enterprise > setting. > > -- > 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! > > On Wed, June 13, 2007 1:17 am, robinbajaj wrote: >> >> 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] >> >> > > > --------------------------------------------------------------------- > 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#a11102261 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
