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#co
mmon_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