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]
