Re: Access to certificates from browser JVMs

Michael and all,

  Some of the thoughts I had and some comments to Michael's post here.

Michael Kirk wrote:
> 
> >
> > Michael Kirk wrote:
> > >
> > > Hi,
> > >
> > > I would like to be able to implement an SSL client within a Java
> > > applet.  In particular I would hope to be able to use client
> > > authentication via the certificates stored and managed by the browser,
> > > or perhaps by the operating system. The only way I'd have access to
> > > these certificate would be if the browser JVM in which the applet ran
> > > provided it in some way.
> > >
> > > I think this is a natural thing to want to do, but as far as I know,
> > > there is no support for it at present. Would someone from the major
> > > browser vendors, be able to comment on whether such access is likely
> > > to become available at any time ?
> >
> > This is a really bad idea, and something that should not be done without
> > a lot of thought and very careful attention to safeguards.  What you're
> > saying is that you'd like to allow java applets to use the user's
> > credentials.  What's to prevent a java applet from connecting to, for
> > example, my stock broker and performing trades without my knowledge?
> >
> > Java applets should behave as seperate entities, not as the user.
> > That's why they are only allowed to connect back to the machine they
> > came from, and not open sockets all over your intranet.
> 
> Clearly the applet would have to be signed (otherwise it wouldn't
> be able to contact the broker anyway - assuming the broker isn't on
> the same machine).  This functionality is needed, otherwise the utility
> of Java applets will be severely limited.  Security is becoming more
> important, and simultaneously there is a trend toward using browsers as
> universal clients running centrally managed software.  Such software needs
> all the functionality of locally managed software if it is to be a viable
> alternative to it.

  I tend to see that there are really two sides to this percieved
need.  First, as to cenertally managed software, it would seem that
providing a certificate type security solution using SSL would be
the most commercially viable and technicaly feasible solution.  This
will most likely require some extension within the JVM or and API
interface that is configurable to the JVM on the server side.

Second, from within a browser, there are several approaches that
we have experimented with that might work well (More on this later
in more detail), it would seem that some alternitive solutions
would be required in order to have some commercial viability.  
some of this could be done by creating some local libs for defination
to that amplett and still and API (Local), though not necessarly part
of the Java JVM would be necessary.  This night also have applications
to push models as well.
> 
> The mechanisms for recognizing, and providing support for, signed applets
> need to be good enough to deal with this situation. An applet that needs
> to act as the authenticated user would have to be explicitly allowed to
> do so by the user (or perhaps by the sysadmin providing the user with
> their browser and their certificates). For example a company xyz might
> have an entity xyz-user-tools which is used only to sign applets that
> need to represent the user via her certificate.  The browsers provided
> by the company to its employees might come pre-configured to provide
> certificate access to applets signed by xyz-user-tools.

  This is one method that we have played around with internaly.  Works
pretty well but has some problems from a managment standpoint. 
Sysadmins
may have a problem with not having more control if the ability from an
individual workstation running Java, had the ability to provide for
a SSL secured applet from that workstation.  So you are really back to a
server solution.  I don't care for this limitation, but it seems
to me that some control point would need to be established.
> 
> I'm not sure where you might see a security problem with this. In the
> stock broker example the mistake is in giving very high level access
> to an applet signed by someone who apparently signs malicious applets.

  Yep, this is the problem with workstation level ability for SSL
interface for certificated amplets.
> 
> >
> > Now, it might be reasonable for a Java applet to have it's own
> > certificate that the client stores (along with the private key) on its
> > behalf to represent that applet running on behalf of that user.
> 
> Having an applet-specific (or perhaps applet-signer-specific) certificate
> managed by the browser would be useful (if that's what you mean). The
> browser JVM would still need to provide an API to it, and the browser
> would need to provide a way of installing it.  Is there any
> plan to provide this functionality ?  Is there any way, in your view
> that (appropriately signed) applets will be able to act as the user on their
> behalf ?  Or do you believe there is no need for this functionality...

  Certianly there is a need.  As I said above we have played with this
experimentaly already.  But as I stated above, there are some problems
with this ability, as you eluded to as well.  However the ability is
really already there to do and and experimental API that we have built
has proven to work fairly well.
> 
> Michael Kirk
> 

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. 
Phone :913-294-2375 (temporary)
E-Mail jwkckid1@ix.netcom.com

Received on Sunday, 9 March 1997 21:49:53 UTC