Will Nordmeyer wrote:
...
Oddly enough, yes, it is a valid use case. we have specific scenarios
where there are common use PCs that have a generic ID logged in,
As far as I remember the classics, that in itself is already a flaw with regard to
security, no ?
> but
> they use their CAC and the browser to access the web application.
Presumably, your application is not the only one running on these workstations. So any
other application must have similar issues. How do they resolve it ?
Assuming that there are many client workstations, and assuming that you cannot control
what's installed on them, then one way I can think of - but it is quite heavy - is to have
every single one of your pages contain a java applet running at all times, which checks
the presence of the card and does something drastic (or doesn't do something vital) in
case the card isn't there, and which causes the server to drop the session)
(I mention the "doesn't do" bit, to avoid the user simply disabling java in the
browser)
One way I could imagine this, would be to have the applet establish its own connection to
the server (maybe on a different port, and send a regular ping to another application on
the server which would keep track of valid sessions. Should the ping no longer come, this
application would somehow tell the main one to abort the session.
It all sounds a bit complicated, but maybe in a very security-conscious environment, this
would be sellable ? (*)
Note that in order for the browser-based java applet to gain access to the local
card-reader, may require some special security settings too.
(*) Come to think of it, it would be rather universal as a solution. and not so complex to
set up. I may have to patent this idea...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
