You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by robinbajaj <ro...@gmail.com> on 2007/06/13 06:21:27 UTC
suggestions for login scheme using struts 1.x
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
--
View this message in context: http://www.nabble.com/suggestions-for-login-scheme-using-struts-1.x-tf3912491.html#a11092549
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by robinbajaj <ro...@gmail.com>.
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: fzammetti@hotmail.com
> 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: fzammetti@hotmail.com
>>> 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: fzammetti@hotmail.com
>>>>> 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: fzammetti@hotmail.com
>>>>>>> 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: user-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>
>> --
>> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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: fzammetti@hotmail.com
>> 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: fzammetti@hotmail.com
>>>> 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: fzammetti@hotmail.com
>>>>>> 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: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
> --
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by robinbajaj <ro...@gmail.com>.
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: fzammetti@hotmail.com
> 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: fzammetti@hotmail.com
>>> 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: fzammetti@hotmail.com
>>>>> 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: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> 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: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>
>> --
>> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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: fzammetti@hotmail.com
>> 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: fzammetti@hotmail.com
>>>> 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: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
> --
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by robinbajaj <ro...@gmail.com>.
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: fzammetti@hotmail.com
> 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: fzammetti@hotmail.com
>>> 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: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>
>> --
>> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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: fzammetti@hotmail.com
>> 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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>
> --
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by robinbajaj <ro...@gmail.com>.
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: fzammetti@hotmail.com
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: suggestions for login scheme using struts 1.x
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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: fzammetti@hotmail.com
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org