[equinox-dev] Re: Client side security store (Peter Kriens)

["Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]

Jay,

The Higgins project will soon (waiting on legal/process issues) have some
early code out. The essence of Higgins is the introduction of an
identity-related IContext abstraction. A context is a group digital identity
objects each of which has a set of attributes and a set of reference to
other correlated identities in related contexts. 

Applications using Higgins first open a root context (called the "user
context") which contains a digital identity object (currently called a
"facet") that represents the user. This user facet's attributes can be
username/password information, keys, and other claims necessary to
authenticate to (or in Higgins parlance to "open) other contexts. Most
applications would define their own context and store in the user context
the credentials necessary for access to their own context.

The code we have today has a toy-like implementation of the user context,
but it makes perfect sense that a real user context impl would wrap the OS
keystores, etc. as was mentioned. In other words, the Higgins project pretty
much has to build what you are looking for. 

The reason I've just been lurking on this list despite my keen interest in
the issues related to client-side keystores, etc, is that the Higgins
project is stretched thin right now just getting our first code ready, along
with a couple of example IContext impl plug-ins, etc. and we don't currently
have a date for when this work will be finished. 

-Paul


-------- Original Message --------
Date: Tue, 27 Sep 2005 18:51:42 -0400
From: jrosenth@xxxxxxxxxxxxxxxx
Subject: [equinox-dev] Re: Client side security store (Peter Kriens)
To: equinox-dev@xxxxxxxxxxx

First, I'm glad to see some great discussions staring up around security 
and Eclipse in general.  As Jeff pointed out, much of the info that was 
started on the Equinox home has become a little out of date.

Peter,

Java has long contained APIs/SPIs for a "KeyStore" which can contain X509 
certificates as well.  As Jeff and BJ point out, some of the default 
implementations are pretty week and can be compromised fairly easily.  The 
IBM implementations in IBM JRE's are "more" secure, in that they use real 
encryption.  The core Keystore APIs/SPIs are very flexible for providing 
your own pluggable implementations and providers.

In addition Java 1.4. introduced the CertStore APIs/SPIs which also 
provide a more robust mechanism for searching and managing groups of 
"untrusted certificates and CRLs".   (see 
http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/CertStore.html
).  I have more experience with the Keystore APIs/SPIs than the Certstore, 
so I won't say anymore about it, until I do.

I believe these APIs/SPIs can be built on to make Eclipse a more secure 
application platform.  I even like the idea of possibly having the 
"default" Eclipse providers, be just wrappers on top of the OS's store.

One of the biggest weaknesses of those APIs is the lack of what is 
probably the most desired piece, a "secure" repository for saving 
username/password combinations for accessing remote services and sites. 
These aren't technically "keys" or certificates, but they do act as a 
user's credentials when accessing some remote services.

Lots of food for thought....

Jay R. 
IBM Corp. , IBM Software Group
Workplace, Portal and Collaboration Software 
Workplace Managed Client, Security 
jsr@xxxxxxxxxx

"Experience is something you don't get until just after you need it." -- 
Anon