[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Client side security store
|
Yes, its called keystore and it is pretty bad :-(
Kind regards,
Peter Kriens
JM> Ok. That makes sense. We don't need to push the frontiers so
JM> secure storage technology but rather enable our users to use the
JM> stuff built by folks who are. I'm hoping that there are already
JM> Java APIs for this level of function?
JM> Jeff
JM> BJ Hargrave <hargrave@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 09/23/2005 07:32 AM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>cc
JM> Subject
JM> Re: [equinox-dev] Client side security store
JM> I am telling you that w/o hardware (e.g. smartcard, TPM) that it is not
JM> really secure. If it is just in a file on the harddisk, then it can be
JM> compromised by software.
JM> But that is probably all that you are really looking for. If there is a
JM> secure store in the OS and that is enough for you, then you could provide
JM> some Java API to front end it.
JM> BJ Hargrave
JM> Senior Software Engineer, IBM
JM> OSGi Fellow and CTO of the OSGi Alliance
JM> hargrave@xxxxxxxxxx
JM> Office: +1 407 849 9117 Mobile: +1 386 848 3788
JM> Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 2005-09-22 11:02 PM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM> Subject
JM> Re: [equinox-dev] Client side security store
JM> Are you saying that I don't have a secure store on my XP box? There must
JM> be one there somewhere. If there is, and it has API, then we should be
JM> able to use it right?
JM> Jeff
JM> BJ Hargrave <hargrave@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 09/22/2005 10:50 PM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM> Subject
JM> Re: [equinox-dev] Client side security store
JM> The only way to get a secure key store is to use hardware like a TPM. You
JM> will also need a secure JVM, etc...
JM> BJ Hargrave
JM> Senior Software Engineer, IBM
JM> OSGi Fellow and CTO of the OSGi Alliance
JM> hargrave@xxxxxxxxxx
JM> Office: +1 407 849 9117 Mobile: +1 386 848 3788
JM> Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 2005-09-22 09:48 PM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM> Subject
JM> Re: [equinox-dev] Client side security store
JM> Thanks Claus for posting that summary. Between the points made by Claus
JM> and Peter it seems we could build enough usecases for a secure store on
JM> the client. We have had a VERY weak one in Eclipse for years but it is
JM> only to keep honest people honest.
JM> So, the question is, who out there has the necessary knowledge to
JM> implement or design such a thing. I assume that most of the building
JM> blocks are already available. No?
JM> Jeff
JM> Peter Kriens <Peter.Kriens@xxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 09/21/2005 05:26 AM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Claus Nyhus Christensen <cnc@xxxxxxxxxxx>
JM> cc
JM> equinox-dev@xxxxxxxxxxx
JM> Subject
JM> Re: [equinox-dev] Client side security store
JM> There has been discussions for the OSGi R4 framework to include a
JM> certificate repository but time did not permit work in this area.
JM> Any work in this direction is very interesting for OSGi because we
JM> currently have a several specifications that require certificates but
JM> we do not have a standardized repository.
JM> Note that the User Admin has some features that move in the right
JM> direction, and which are protected with Java 2 security.
JM> Kind regards,
JM> Peter Kriens
CNC>> Hi,
CNC>> I am currently working on creating an Eclipse RCP front end for the
JM> J2EE
CNC>> Adventure Builder Blueprint application
CNC>> (http://java.sun.com/blueprints). I am doing this work with Nick
JM> 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
JM> 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
JM> J2EE
CNC>> vendor and most of my work has been in this field. I have some
JM> (minor)
CNC>> experience with Eclipse RCP, and working with Nick and Pascal really
JM> 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
JM> 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
JM> 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
JM> have
CNC>> to deal with user names and passwords (for different users and
JM> 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
JM> a
CNC>> national system where every citizens can get a digital signature
JM> which
CNC>> can be used when communicating with the government (tax, health care
JM> 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
JM> are
CNC>> kind of hard to manage on the client side (you have to install them
JM> 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
JM> 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
JM> key
CNC>> chain, on Linux (Gnome) they have a key ring, and I am sure that
JM> Windows
CNC>> has a similar thing. These systems are basically security stores
JM> where
CNC>> you can store user names, passwords, digital signatures and then
CNC>> retrieve them at a later point. Integration with these security
JM> 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
JM> client
CNC>> machines and the RCP applications will then easily be able to use
JM> 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
JM> would
CNC>> be good tools for the programmer to have when dealing with client
JM> side
CNC>> security. Maybe it can serve as a starting point for further
JM> discussion.
CNC>> Regards
CNC>> Claus Nyhus
CNC>> Trifork
JM> --
JM> Peter Kriens Mob +33633746480
JM> 9C, Avenue St. Drézéry Tel +33467542167
JM> 34160 Beaulieu, France Tel +15123514821
JM> Tel +33870447986
JM> AOL,Yahoo, Skype pkriens ICQ 255570717
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
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
