app...@dsl.pipex.com wrote:
Not sure about which version of security I will use but I would like to accommodate MD5
verification into things. There's no sensitive or confidential info in the system either so
protected page access may not be required.
I don't know what you have in mind, but there are some basic principles to
avoid wasting
your time :
1) In Tomcat (and other servlet engines), there are 2 different ways of doing
authentication :
- declarative, as per web.xml. In that case Tomcat, /before it evens calls the
webapp or
any filter in it/, intercepts a non-authenticated call and returns *the* login
form to the
browser. It then (later) intercepts the submit of that form by the browser,
checks the
credentials, and if they pass muster, it allows the call to proceed to the
webapp which
the user wanted in the first place.
- application- or filter-based authentication : in this case, Tomcat is not
aware that
there is an authentication taking place. It forwards the call to the webapp,
and a filter
/in the webapp/ intercepts the call and does whatever is needed to check the
authentication, return a login form etc..
This second authentication scheme is probably more flexible for doing the kind
of thing
you seem to want to do (but also more complex to do).
2) There already exist a number of authentication systems on the market. Unless this is
considered as an exercise, re-use an existing one instead of rolling you own. Web
authentication looks deceptively simple, but is in fact quite complex and delicate, and
open to many mistakes which completely defeat the purpose.
(This being said, if it is an exercise, it is an interesting area).
3) anything that your server sends to a browser should be considered "open and
lost".
Once you send something out there, the recipient can do with it what
he wants : save it, analyse it, copy it, decompile it, falsify it, re-send it
to your
server and whatnot. There is no practical way to avoid that.
(You don't even know that it is really a browser out there).
4) the only good way to secure things if you do form authentication, is to work
over HTTPS.
The customer is going to type a login-id and a password, in the form, in clear.
The browser is going to send this over HTTP to the server.
Anyone who can "sniff" this traffic is going to see what is sent.
And even if he does not understand it, he can record it and replay it.
But not under HTTPS.
5) users always take the easy path. That means that, if they can choose their
password,
they will pick the same one as the one they use already for their network login, for their
email account, for their bank account, etc.. So if anyone subverts /your/ login system -
even if on /your/ server there is nothing vital to grab - the damage is probably not
limited to your server. You don't want to be accused of facilitating the bad guy's job.
6) If you are thinking of encrypting the data in the browser, it's probably not
worth the
effort. For that, you will have to write some special code, and download it to
the
browser to run it there. Once you do that, it can be saved, analysed, replicated,
falsified, disabled.
So why bother ?
HTH. Been there, etc..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
