Re: [equinox-dev] Client side security store

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Are you saying that I don't have a secure
store on my XP box?  There must be one there somewhere.  If there
is, and it has API, then we should be able to use it right?

Jeff

BJ Hargrave <hargrave@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

09/22/2005 10:50 PM

Please respond to
Equinox development mailing list

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Client side security store

The only way to get a secure key store is to use hardware
like a TPM. You 
will also need a secure JVM, etc...

BJ Hargrave
Senior Software Engineer, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
2005-09-22 09:48 PM
Please respond to
Equinox development mailing list


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
Re: [equinox-dev] Client side security store







Thanks Claus for posting that summary.  Between the points made by
Claus 
and Peter it seems we could build enough usecases for a secure store on
the client.  We have had a VERY weak one in Eclipse for years but
it is 
only to keep honest people honest. 

So, the question is, who out there has the necessary knowledge to 
implement or design such a thing.  I assume that most of the building
blocks are already available.  No? 

Jeff 



Peter Kriens <Peter.Kriens@xxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
09/21/2005 05:26 AM 

Please respond to
Equinox development mailing list


To
Claus Nyhus Christensen <cnc@xxxxxxxxxxx> 
cc
equinox-dev@xxxxxxxxxxx 
Subject
Re: [equinox-dev] Client side security store








There has been discussions for the OSGi R4 framework to include a
certificate repository but time did not permit work in this area.

Any work in this direction is very interesting for OSGi because we
currently have a several specifications that require certificates but
we do not have a standardized repository.

Note that the User Admin has some features that move in the right
direction, and which are protected with Java 2 security.

Kind regards,

    Peter Kriens

CNC> Hi,

CNC> I am currently working on creating an Eclipse RCP front end for
the 
J2EE
CNC> Adventure Builder Blueprint application
CNC> (http://java.sun.com/blueprints). I am doing this work with Nick
Edgar
CNC> and Pascal Rapicault in preparation for a joint tutorial at the
JAOO
CNC> conference next week.

CNC> During this work we discussed client side security. Jeff McAffer
got
CNC> involved in the discussion, and he asked me to post some of my
thoughts
CNC> on this mailing list :)

CNC> As a start I must say that I am a "J2EE person", i.e.
I work for a 
J2EE
CNC> vendor and most of my work has been in this field. I have some
(minor)
CNC> experience with Eclipse RCP, and working with Nick and Pascal really
got
CNC> me hooked on making "fat clients"/Smart Clients for J2EE
again.

CNC> Well, on to the subject:

CNC> Being from the J2EE world I am used to having support for security
CNC> functionality in the framework and tools. I can e.g. configure
key 
and
CNC> trust stores for SSL communication, the browser can cache my username
CNC> and password when I log in to a web application and so on. When
I 
want
CNC> my user interface to be a Smart Client I am more of less on my
own.

CNC> Therefore, in out opinion Eclipse RCP would benefit greatly from
have
CNC> some kind of security housekeeping support. In simple scenarios
you 
have
CNC> to deal with user names and passwords (for different users and
different
CNC> back end connections). Often you cannot simply cache them on the
CNC> connection but have to cache them locally in your program. 
CNC> Furthermore, in Denmark digital signatures play a major role (we
have 
a
CNC> national system where every citizens can get a digital signature
which
CNC> can be used when communicating with the government (tax, health
care 
and
CNC> so on)) and I expect it to be just as big in other countries. While
CNC> digital signatures can be handled pretty easily on the server they
are
CNC> kind of hard to manage on the client side (you have to install
them 
in
CNC> your trust store and so on).

CNC> Based on this we think that it would be really great if Eclipse
CNC> RCP had some kind of API and security store for helping to manage
this.
CNC> While a pure Java solution could be developed, we think it would
be
CNC> better to provide some kind of bridge to the security store of
the
CNC> operation system, providing for the possibility to share security
CNC> settings between applications. On OSX they have something called
a 
key
CNC> chain, on Linux (Gnome) they have a key ring, and I am sure that
Windows
CNC> has a similar thing. These systems are basically security stores
where
CNC> you can store user names, passwords, digital signatures and then
CNC> retrieve them at a later point. Integration with these security
stores
CNC> though a common Eclipse RCP API would in our opinion be a major
thing
CNC> for client security. I can imagine scenarios where a system
CNC> administrator can push digital signatures to security stores on
client
CNC> machines and the RCP applications will then easily be able to use
them
CNC> for connecting to web services and so on.

CNC> I do not know that much about these security stores from a technical
CNC> point of view, so the above is really just ideas for what we think
would
CNC> be good tools for the programmer to have when dealing with client
side
CNC> security. Maybe it can serve as a starting point for further 
discussion.

CNC> Regards
CNC> Claus Nyhus
CNC> Trifork



-- 
Peter Kriens                  
           Mob +33633746480
9C, Avenue St. Drézéry              
     Tel +33467542167
34160 Beaulieu, France              
     Tel +15123514821
                    
                    Tel
+33870447986
AOL,Yahoo, Skype pkriens              
   ICQ 255570717

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev