Re: [geclipse-dev] Secure storage usage in headless RCP app using g-Ecli

[Ariel Garcia <garcia@xxxxxxxxxx>]

Hi Kasia,

> I was investigating the problem of secure storage in headless RCP app
> using g-Eclipse plug-ins, which may be a bit tricky so I'm describing my
> experiences here in case anyone encounters the same problem in the
> future. And also there's a question if we can make things easier in
> g-Eclipse when it comes to secure storage.

in the past... i've encountered it last week already ;-)
I commited a couple of changes last friday or so, but i guess your 
investigations will be very useful to improve it.

What i did: added a public method to disable secure storage (ie, only use 
the gEclipse internal store), and changed the code to handle all the 
exceptions from secure storage immediately disabling SS if one happens. 
This makes the code more robust to failures but might not be the best 
option.

I will carefully read your conclusions later.

Cheers, Ariel

> My use case is to have headless RCP application (I have GUI, but Swing,
> not SWT-based) using g-Eclipse plugins as a grid access API, e.g.
> creating grid proxy using classes in eu.geclipse.globus.auth packages.
> In my app I have fields for providing path to user cert and key files
> and then password - this information is passed to g-Eclipse auth
> mechanism which is taking care of e.g. loading user's key using the
> password. Everything worked fine on windows, but when I tried the same
> run configuration on Linux I got
> org.eclipse.equinox.security.storage.StorageException saying "No secure
> storage modules found."
>
> That was because secure storage implementations are operating system
> specific:
> - the Windows-specific module in the
> org.eclipse.equinox.security.win32.x86 - the Mac-specific module in the
> org.eclipse.equinox.security.macosx - the default UI module in the
> org.eclipse.equinox.security.ui
>
> Basically switching from OS specific module to the default one
> (org.eclipse.equinox.security.ui) solves the problem, but only in terms
> of runtime exceptions. In headless RCP, when there is no workbench
> available, using default secure storage will result in storing your
> password in non-encrypted value. There are 3 workarounds for that:
> 1. creating your own password provider module (see the extension point
> org.eclipse.equinox.security.secureStorage)
> 2. using the "-eclipse.password" runtime option to specify the file
> containing master password
> 3. creating and running in background a workbench instance (which will
> trigger Eclipse's mechanisms for encrypting your password with master
> one you will be asked for).
>
> As adapting one of the solutions may be either time-consumptive or not
> elegant there's a question if it would be possible to make usage of
> secure storage in g-Eclipse auth mechanism optional?
>
> Cheers,
> Kasia