Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Plug-in Developer Guide
Previous Page Home Next Page

Secure Storage Architecture

From a logical perspective secure storage represents a hybrid of OSGi's Preferences and a keyring.

The front end is modeled in a fashion very similar to the OSGi Preferences Service specification . Secure storage is represented as a tree of nodes. Nodes provide context. For instance, a bundle "com.abc" could use the node "abc" under the node "com" under the root node. As in Preference's, the path to such node can be described as "/com/abc".

Logical organization of data in secure storage

Picture 1. How the data is organized.

The data is stored under the node as a key-value pair. The data can be stored in an encrypted form or as a clear text. The ability to store clear-text data is provided so that logically related information (such as non-encrypted user name and encrypted password) can be stored using the same mechanism.

The code to store a password associated with "com.abc" could look like this:

	...
	ISecurePreferences root = SecurePreferencesFactory.getDefault();
	ISecurePreferences node = root.node("/com/abc");
	node.put("password", "12345", true /*encrypt*/);
	...

and then to retrieve the data:

	...
	String password = node.get("password", null /*default*/);
	...

If secure storage was modified, it will be saved when the application is closed. Alternatively, a save can be triggered programmatically by calling ISecurePreferences#flush().

On the back end, secure storage can be thought of as a keyring. Each entry is associated with a password provider; only this password provider can be used in the future to decrypt the entry.

Secure storage entries and password providers

Picture 2. Relationship between entries and password providers.

Secure storage has provisions to obtain the master password from various sources described by password providers. Even more importantly for developers, the set of password providers is open and easily customizable.


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire