The Secure Storage API 
Use
The SAP J2EE Engine has a secure storage area where you can store security-relevant information such as passwords in encrypted form.
Integration
Encryption Routines
The algorithm used for the encryption is the symmetric encryption algorithm triple DES (Data Encryption Standard) using a 168-bit secret key. The same key is used for both encrypting and decrypting the data. A unique secret key is assigned specifically to the application when it requests access to the secure area. The secret key itself is stored in the server’s keystore. As an alternative, objects can be encoded using base 64 encoding.
This key can be changed at a later time. For more information, see the examples provided or Replacing an Application’s Secret Key in the Administration Manual.
Security Product
The encryption and decryption routines are performed by the SAP Java Cryptographic Toolkit, which due to export regulations, is not directly available with the SAP J2EE Engine. It is available for download on the SAP Service Marketplace. Note however, that it is not available to all customers.
To obtain the SAP Java Cryptographic Toolkit, see service.sap.com/download. For instructions about how to install it on the SAP J2EE Engine, see Deploying the SAP Java Cryptographic Toolkit in the Administration Manual.
For you development, this means you have to handle the corresponding exceptions for the case that the security product is not available.
Storage Approaches
Your application can either centrally store the data object in the secure storage area or it can store it in de-centrally. If your application stores the object centrally, then the Secure Storage service manages the storage and administration of the data. If you use the de-central storage approach, then your application has to manage these tasks itself.
Affected Services
The Secure Storage and Key Storage services and the database must be running when the application requests access to the secure storage area. For your development, this means you have to handle the corresponding exceptions for the case that services do not respond.
Activities
The following activities occur when an application uses the secure storage area:
...
1. The first time an application requests access to the secure storage area, the server assigns it an application-specific storage location in the secure storage area, called a context. The application’s context is then identified using the client type ( webapp or service) and a client ID.
The server also assigns a unique secret key to the application, which is stored in the J2EE Engine’s keystore as an entry in the securestorage view.
There are two types of contexts available using the secure storage interfaces, a client context and an administrator context. The administrator context is only to administrators, for example, when using the Visual Administrator. Applications and services are to obtain client contexts for their secure storage operations.
2. Once an area has been assigned to the application, the application uses the Secure Storage service and its unique secret key to encrypt a data object. Unless your application uses a decentralized storage approach, then the object is also stored in the secure storage location that is assigned to your application. For identification, the object is assigned an object ID.
3. When the object is needed at a later time, the application retrieves the data object from the secure storage area and decrypts it, also using its unique secret key.
If the application uses the decentralized storage approach, then it must retrieve the data object independently. It can then use the Secure Storage service to decrypt the data using its secret key.
Interfaces and classes are available for these tasks. In addition there are interfaces available for changing an application’s secret key, as well as for modifying or deleting data objects.
For more information, see Interfaces and Classes for Using Secure Storage and Examples for Using Secure Storage Interfaces and Classes.