Please note that Eclipse provides such a functionality out of the box. The secure storage is managed by Eclipse and you just need to save your sensitive configuration data (password). There is no need to provide a password when reading the data (at least on Windows at Eclipse has an integration with the Windows authentication layer).
I have used it in my Eclipse based product, and for security reasons, I choose to make it non optional.

Jeff


On Wed, Apr 3, 2013 at 10:43 AM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
Very interesting things.

Thanks Emmanuel and Kiran for your hard work on all that and sharing it with us. :)

On my side, I worked on fixing important bug fixes for issues that were mainly introduced in the last release of Apache Directory Studio.
A release is ready, but I don't know if I should wait for a new release of ApacheDS (fixing the bugs we have around password policies and stuff like that) or release Studio ASAP (and eventually release another version when ApacheDS is fixed)

You tell me what's best. ;-)

In the past week, I've been working on a interesting and very important feature for Apache Directory Studio: secure storage of connections passwords into a password-protected keystore.

At the moment, when you check the "Save password" checkbox in the properties of a connection, that password gets saved in the connections file alongside other parameters like host, port, etc.
The problem is that the password is saved in clear text in the file and that could be an issue for some users.

So, the idea is to have an option (disabled by default) in Apache Directory Studio to save the passwords of the connections in a keystore protected by a "master password". This password would be asked when accessing the password of a connection (opening a connection for example).

This is a very low-level addition in Studio's code and a very sensitive refactoring, so I'm extra cautious here.

I really think we can't release a 2.0 version of Studio without this kind of functionality. It's really a must-have.

Regards,
Pierre-Arnaud

On 2 avr. 2013, at 19:53, Emmanuel Lécharny <elecharny@gmail.com> wrote:

> Hi guys,
>
> it was two tough weeks, with merely no work on the server... But still,
> we made some progress on some side projects critical to ApacheDS. Let me
> provide some headsup.
>
> 1) We are making progress on Mavibot. Mavibot is the backend replacement
> for JDBM. Currently, we are able to manage the additions, deletions and
> modifications in it. The performances are good, assuming the right page
> size/nb of elements per page are correctly set (up to 13 000 updates per
> second). The searches are blasting fast : 1 600 000 lookup per second.
>
> Kiran has added support for multiValues in it, and is currently testing
> a partition for mavibot. I let him giving some feedback on this part,
> but I'm quite exited !
>
> We have a lot to do, still. We currently never remove any revision, so
> the file keeps growing after each modification. Kiran is working on a
> bulk load mechanism. I'm working on a mechanism that reclaim the pages
> that are not anymore in use.
>
> We will have to add a way to access the old revisons too and I'm
> currently working on that. This will allow us to get rid of the
> ChangeLog system, as it will now be just a matter to switch to an old
> revision to get back to the previous data set. That will make the test
> way faster !
>
> I expect to have Mavibot completed by the end of april.
>
> 2) MINA 3 is also on its way, and sounds promizing. It's already 50%
> faster than MINA2, which is a huge gap. I hope to be able to build a
> working prototype based on MINA 3 by the end of april too.
>
> 3) In the mean time, I think we can get a 2.0-RC1 released. We have
> fixed some serious bugs lately, and I don't think we will add new
> features in this version.
>
> All in all, I think that once 2.0 will be out, we will be able to switch
> to Mavibot backend and MINA 3, to get way better performances.
>
> 4) The documentation
>
> It *absolutely* sucks :/ I have tried to improve the Kerberos
> documentation last month, it was a lot of work, as the kerberos server
> was also quite buggy. There is a lot to do, since we switched to the new
> system last year, we haven't made a lot of progress in this area. This
> is true for the server but also for the API. I can't seriously see how
> we can get a 2.0-GA if the documentation is not improved in one way or
> another... It's useless to have a fast and working server, if no one
> know how to use it :/
>
> That's pretty much it, Kiran, feel free to complete this mail.
> Pierre-Arnaud, sorry if I haven't mentionned what you have done on
> Studio, so please, feel free to add your progress !
>
> Many thanks guys !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>




--
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury