thanks for sharing your valuable experiences on this topic with me. I think I will come back with more questions... :-) but for now, its good ! thanks once again, robbby
Frank W. Zammetti wrote: > > No, your conceptualizing it a bit more complex than it is. > > Your web server will (generally) serve unprotected resources, i.e. images, > help files, things of that nature. Your app server will handle security > for your application in the sense that you constrain certain parts of the > application (or perhaps all of it) using J2EE security. > > Now, if you have protected resources on the web server too, then yes, > things get a little more complicated (and honestly, the last time I > personally had to set something like that up was years ago, we use a > hosted environment now, so I'm not even sure I'd know how to do it off the > top of my head). > > Now, all this being said, you very well may not have a need for the > web/app server setup... just an app server might do the trick for you just > fine, many people do run that way. I think it's fair to say that's a > simpler setup, but I didn't want you thinking it was a total nightmare to > have both "tiers", so to speak, in the mix. > > 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! > > On Wed, June 13, 2007 12:37 pm, robinbajaj wrote: >> >> my issue with having a web-server in front of app-server is, >> that adds to complexity of the login architecture. >> >> If I have my webServer in front of the appServer, (for the reasons you >> mentioned), >> I have to have a login web app running on webServer, and the actual >> business-app running >> on appServer. loginWebApp authenticates the user, and then I have to use >> some single-signon >> while passing on the control from webServer to the appServer. (What I >> explained earlier in my first post, can be considered as our home-grown >> single-signon solution that uses session cookies etc. I can use any other >> single signon framework like Acegi's http://www.ja-sig.org/products/cas/ >> CAS etc. ) >> >> But my question is, doesn't having a webServer in front of appServer, >> unnecessarily adding complexity to the login scheme. >> >> Another proposal that I have in my mind is to have the user log in >> straight >> to the appserver (that hosts ONE web-app handling BOTH the login and the >> actual business), and then whenever a request for a static resource is >> made >> from the mainpage, I can direct the user to the webServer etc. >> This way, webServer still gets to serve what it serves best, offloads the >> appServer from doing the menial static content serving etc. and leaves me >> with a simplified login architecture. >> >> What do you think about my thoughts above, >> thanks for your help, >> regards, >> robby >> >> >> Frank W. Zammetti wrote: >>> >>> Typically, the web server is what receives the request... it then >>> determines what type of resouce is being served, and if its something >>> that >>> the app server needs to handle (a servlet for instance), it passes the >>> request along. So in a very real sense it's "in front" of the app >>> server. >>> >>> Now, take something like Tomcat for instance... it essentially has a web >>> server built in. I've never seen one, but if someone drew a Tomcat >>> architecture diagram, I'd expect to see the web server component in >>> front >>> of the servlet container component, acting something like a proxy >>> (having >>> said that, someone will inevitably tell me I'm wrong!). >>> >>> Probably the primary benefit to this is that you offload work from the >>> app >>> server and let the web server serve resources that it generally can more >>> efficiently. >>> >>> 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! >>> >>> On Wed, June 13, 2007 11:36 am, robinbajaj wrote: >>>> >>>> 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] >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> 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#a11103512 >> 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#a11104460 Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
