The KAM supports the ability to perform cryptographic operations on large sets of plaintext data in batch mode, as opposed to sending each request in a unique web service call. As fast as SAKA is, batch mode operations—especially for decryption—are sped up significantly through the avoidance of many functions that are repeated for each web service call.

SAKA supports all four (4) types of cryptographic operations: encryption, decryption, deletion, and searching. There are no limits to the number of records that may be processed within each batch operation. However, each of the operations must meet the following prerequisites:

• The input file for the batch operation must conform to the SKLESBatchInput (SBI) element of the SAKA XML Schema Definition (XSD), which is included on every appliance, and is shown later in this chapter.

• The XML input file must be transferred to SAKA separately; StrongKey recommends the use of the Secure File Transfer Protocol (SFTP), but Network File System (NFS) and/or Server Message Block (SMB) protocols may also be used to transfer files to the appliance. Each encryption domain must have an operating system user defined with a home directory writable by the strongauth user to enable the batch operations. Note that the installation of a new appliance automatically creates the first encryption domain and a batch operation user called domain1 at the Linux operating system layer to enable the file transfers through SFTP. When additional encryption domains are made, batch operation users must be added manually to enable the file transfer capability.

• The batch operation must be requested through a web service—the same web service that supports all other cryptographic operations. The Demo Client application described in the previous chapter—sakaclient.jar—has sample code to show how the web services may be requested; this chapter uses the demo application in its examples below.

• The user requesting the batch operation must be authorized for the cryptographic operation.

After the batch operation is completed, SAKA creates the output as an XML file, conforming to the SKLESBatchOutput (SBO) element from the SAKA XML Schema Definition (XSD). The output must be transferred from the appliance similarly to how the input file was transferred. After the file is transferred by the batch operation user, it must be deleted explicitly, as some of the operations (encrypt, decrypt, and search) result in creating output files that contain sensitive data in an unencrypted form.

NOTE: SAKA deletes input files for the encryption and search operations immediately after completing the batch job; however, it does not delete the input files for the decryption and deletion operations since they only contain tokens.