SSL Authentication using Java or JSP

S

Susanne Kaufmann

Hello,

I have a website with client-certs, so only users with a correct cert
can connect to the site. Now I wanted to update the whole thing: I put
the cert on a smartcard. So far, so good.

But: I do not want this browser-popups, where I have to select the cert
I want to use, and the popup to "insert card", when no smartcard is
inserted.

Instead of these I would like to use a Java Applet which communicates
with my card reader, and gives the information, e.g. the cert to the
browser, but without these popups. When there is something wrong, the
Java applet should manage this, e.g. when there is no card in the
card-reader.

The main question is: how can I intercept or avoid the browser popups?

Regards,

Susanne
 
J

Jan Peter Stotz

Susanne said:
Instead of these I would like to use a Java Applet which communicates
with my card reader, and gives the information, e.g. the cert to the
browser, but without these popups. When there is something wrong, the
Java applet should manage this, e.g. when there is no card in the
card-reader.

Establishing a SSL-connection authenticated by a certificate from a
smartcard shouldn't be too hard. The main problem is the communication
applet <-> browser. For this communication the browser would have to
provide an interface the applet could use. AFAIK none of the main browser
has such an interface.
The main question is: how can I intercept or avoid the browser popups?

Why? May be the problem is the browser you are using...

Jan
 
O

Oliver Wong

Jan Peter Stotz said:
Establishing a SSL-connection authenticated by a certificate from a
smartcard shouldn't be too hard. The main problem is the communication
applet <-> browser. For this communication the browser would have to
provide an interface the applet could use. AFAIK none of the main browser
has such an interface.

In other words, it is exceedingly hard, bordering on the impossible. ;)

Even if you did find one particular browser which provided this
interface, it wouldn't be part of the "Java applet interface" (for lack of a
better name), which means you'd probably have to do strange JNI hacks, and
it wouldn't work accross all browsers.

The best I can come up with is to get rid of the browser alltogether,
and implement an HTML parser and renderer yourself within your Java
application (which might as well be distributed via WebStart instead of as
an embedded applet). If you're satisfied with HTML 3.2 without CSS, you can
go with Suns built in HTML rendering engine.
Why? May be the problem is the browser you are using...

I don't a "good" browser *should* try to notify the user whenever an SSL
connection fails due to missing certificates (and doing so via a pop up
dialog seems as good a method as any).

- Oliver
 
R

Rogan Dawes

Oliver said:
In other words, it is exceedingly hard, bordering on the impossible. ;)

Even if you did find one particular browser which provided this
interface, it wouldn't be part of the "Java applet interface" (for lack
of a better name), which means you'd probably have to do strange JNI
hacks, and it wouldn't work accross all browsers.

The best I can come up with is to get rid of the browser alltogether,
and implement an HTML parser and renderer yourself within your Java
application (which might as well be distributed via WebStart instead of
as an embedded applet). If you're satisfied with HTML 3.2 without CSS,
you can go with Suns built in HTML rendering engine.


I don't a "good" browser *should* try to notify the user whenever an
SSL connection fails due to missing certificates (and doing so via a pop
up dialog seems as good a method as any).

- Oliver


One thing that may be possible is to protect different parts of your
site differently.

That is, allow users to download your applet from an SSL-protected part
of the site that does NOT require client side certs. Then, your applet
connects to URL's that DO require client-side certs, and might be able
to handle the error conditions that you describe internally, without
letting the browser get involved.

Regards,

Rogan
 
S

Susanne Kaufmann

That is, allow users to download your applet from an SSL-protected part
of the site that does NOT require client side certs. Then, your applet
connects to URL's that DO require client-side certs, and might be able
to handle the error conditions that you describe internally, without
letting the browser get involved.

This sounds very good. But do you have an idea how to do only the
client-side-authentication inside the JavaApplet and then go back to
the browser?

E.g: There is a SSL-protected part of the site (client-side-certs not
required), where the Applet can be loaded. Now the Applet connects to
an client-side-cert-required URL. After success it redirects the
browser into the secured area. Or is in impossible to do so, because
only the applet is now authenticated, but not the browser?

Regars,

Susanne
 
R

Rogan Dawes

Susanne said:
This sounds very good. But do you have an idea how to do only the
client-side-authentication inside the JavaApplet and then go back to
the browser?

E.g: There is a SSL-protected part of the site (client-side-certs not
required), where the Applet can be loaded. Now the Applet connects to
an client-side-cert-required URL. After success it redirects the
browser into the secured area. Or is in impossible to do so, because
only the applet is now authenticated, but not the browser?

Regars,

Susanne

Well, the obvious thing is for the applet to authenticate a session, by
means of connecting to the client-cert protected URL. Now, I have no
idea whatsoever if the applet would be able to read/write a browser
cookie, so this may be completely unworkable.

For example:

Browser connects to the site, is issued a cookie containing a session id.

Browser downloads the applet. Applet connects to the client-cert
protected URL. The app at that URL gets the information from the client
cert, and writes it into the user's session, i.e. authenticates the session.

The browser then accesses various pages as expected, since it now has an
authenticated session.

NOTE NOTE NOTE NOTE NOTE !!!!!!!

This is not necessarily the best way to do this!!! If anyone is able to
get the sessionid, via XSS (Cross site scripting), or whatever, they
would still be able to masquerade as the user, and access sensitive
information.

The best solution would probably be to implement your app as a kind of
Ajax-ish solution, with your applet doing all the work, communicating
with the server, sending and retrieving data, and writing it out to the
browser DOM to provide an interface to the user.

In this way, all the sensitive data is conveyed over client-cert
authenticated connections, and you have the guarantee that there is no
access to sensitive info without the client cert.

You could allow access to empty template pages via the browser, without
requiring client certs, and then populat them with data using your applet.

Check out the following links for details:

http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/java_js.html#common_dom

and

http://java.sun.com/j2se/1.4.2/docs/guide/plugin/dom/index.html

You'll probably also want to take a look at some Ajax tutorials to get
some ideas on how to get your data into the pages.

An approach might be something like the following. I'm assuming that
you'd be using frames, so that your applet would have a long life, and
could continue to manage the smart-card and credentials. (i.e. it is not
reloaded with every page change). The applet may be in a hidden frame,
for example.

Then, the applet could instruct the browser to load empty/data-less
template pages from a "non-client-cert-protected" part of the site.

The applet would then use AJAX-ish techniques to retrieve data from the
site, using client-cert-protected (CCP) connections, managed by the
applet, and update the template pages accordingly.

Alternatively, you could program your HTML pages to retrieve data via
the applet, so that you don't need to implement all the functionality in
the applet itself. Your applet would then become a kind of general
XmlHttpRequest object, that also happens to make sure that the requests
are made using a client-cert-protected connection. This is probably a
better solution than implementing all the site's functionality in the
applet itself.

Good luck.

Rogan
 
S

Susanne Kaufmann

If I understand you correctly it would be possible to load the contents
of the pages via the applet. When the Applet has a correct cert, then
it gets the "intern" data.

But do I have to use Ajax for this? At the moment my site uses PHP.

I guess it is right, that the applet should not contain the full
functionality of the site. But how can I submit the request to the Java
applet? E.g. when there is a link "intern.php", then this should not be
send directly to the browser but to the applet. The applet now gets the
data and inserts it into the site-template?

What would be about another possibility: A hidden frame with the Java
Applet, like you mentioned before. And now, when the "intern"-area
should be entered, e.g. "intern.php", the site asks the applet if it is
"logged-in". If yes, the page is shown, otherwise it is redirected to
login.

Or is the variant unsafe?

Regards,

Susanne
 
O

Oliver Wong

Susanne Kaufmann said:
What would be about another possibility: A hidden frame with the Java
Applet, like you mentioned before. And now, when the "intern"-area
should be entered, e.g. "intern.php", the site asks the applet if it is
"logged-in". If yes, the page is shown, otherwise it is redirected to
login.

Or is the variant unsafe?

This last variant is probably unsafe in that authentication is now
happening on the client side instead of on the server side. I could write an
applet which simply always says "Yes, I'm logged in" and play around the
browser, cache or network stack so that my applet gets downloaded whenever
there's a reference to your applet.

And when you say "the site asks the applet", I'm guessing you mean
something like "Javascript embedded within the HTML that the user receives
asks the applet", which opens up further vulnerabilities of the user-agent
ignoring the JavaScript code, or changing it.

- Oliver
 
R

Rogan Dawes

Susanne said:
If I understand you correctly it would be possible to load the contents
of the pages via the applet. When the Applet has a correct cert, then
it gets the "intern" data.

But do I have to use Ajax for this? At the moment my site uses PHP.

I guess it is right, that the applet should not contain the full
functionality of the site. But how can I submit the request to the Java
applet? E.g. when there is a link "intern.php", then this should not be
send directly to the browser but to the applet. The applet now gets the
data and inserts it into the site-template?

What would be about another possibility: A hidden frame with the Java
Applet, like you mentioned before. And now, when the "intern"-area
should be entered, e.g. "intern.php", the site asks the applet if it is
"logged-in". If yes, the page is shown, otherwise it is redirected to
login.

Or is the variant unsafe?

Regards,

Susanne

You can certainly implement AJAX-ish behaviour using PHP.

http://www.google.com/search?q=ajax+php

gives a ton of results.

Or else JSON (HTTP://www.json.org/), which is basically the same thing,
just not using XML, but rather datastructures created using JavaScript.

The whole point of using the applet to get the data (i.e. the
crown-jewels of your site), is that the applet can always strongly
authenticate itself, which the browser by itself can't (because it pops
up prompts, and tries to manage the smart-card itself, which you don't
want).

One other way of doing this that does not require Ajax-ish behaviour is:

Every time you load a page, you first use the applet to get a token,
which you include in the request to the site. The site then verifies
that the token is valid, then invalidates the token, and returns the
requested data.

e.g. make all of your links call a "authenticateRequest()" function in
your applet that makes an SSL call to the server, retrieves a new cookie
value, and sets it in the browser, and then allows the link click to
continue, so the browser sends the new cookie to the server as part of
the request.

Downside is that there is now a double-round trip for every request.
(which may be worked around by making the applet's connection to the
server persistent, perhaps).

But this is also a very clumsy solution, that I don't think terribly
much of.

Regards,

Rogan
 
S

Susanne Kaufmann

e.g. make all of your links call a "authenticateRequest()" function in
your applet that makes an SSL call to the server, retrieves a new cookie
value, and sets it in the browser, and then allows the link click to
continue, so the browser sends the new cookie to the server as part of
the request.

Thank you for spending your time. Sorry, but what do you mean with
"setting a new cookie value in the browser"? I understand the things
before (I hope). The browser wants to open a site, the site calls a
authenticateRequest to the Java-Applet. But what happens then? Why do I
need a new Cookie-Value?

Regards,

Susanne
 
O

Oliver Wong

Susanne Kaufmann said:
Thank you for spending your time. Sorry, but what do you mean with
"setting a new cookie value in the browser"? I understand the things
before (I hope). The browser wants to open a site, the site calls a
authenticateRequest to the Java-Applet. But what happens then? Why do I
need a new Cookie-Value?

The new cookie acts as a security token. The Applet autenticates itself
and asks for a password. The server checks the credentials, then gives the
applet the password. The applet gives the password to the browser. The
browser tries to connect to the site using the password from the applet. The
server checks the password, then changes it. It'll only tell the new
password to the applet, not the browser.

- Oliver
 
S

Susanne Kaufmann

The new cookie acts as a security token. The Applet autenticates itself
and asks for a password. The server checks the credentials, then gives the
applet the password. The applet gives the password to the browser. The
browser tries to connect to the site using the password from the applet. The
server checks the password, then changes it. It'll only tell the new
password to the applet, not the browser.

Thank you very much for your patience.

Ok, if I understand you correctly, the cookie works as password. The
applet authenticates itself to the server and asks for a password. The
server now generates a password and submits this to the applet (and
stores it in a database). The applet gives the password to the browser,
which can initialize this as a cookie. Then the browser connects to the
requested site. This site looks up in the database if there is the
browser's cookie value in.

Regards,

Susanne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top