To test SAKA web services, the appliance comes with a Java-based client application that can be used to test the web service operations of the SAKA server. The Java client—called sakaclient.jar—can be used to call web service operations on a DEMO appliance on the internet—demo.strongauth.com—or on the SAKA cluster within a network.

The DEMO SAKA uses the identical software as appliances delivered to customers. This allows application development teams to verify their code without having to wait for a SAKA implementation internally. Once verified against the DEMO SAKA, the identical code will work against the internal SAKA implementation without changing a single line of code. The only differences would be the URL of the host and the parameters passing at runtime. (We recommend parameterizing the URL of the appliances being called; this will make it easier to point applications to SAKA during deployment to production).

The client application is a simple Java application that calls the web service on SAKA to perform one of many operations; it simulates what the applications must do to call the EncryptionService on the SAKA server. While the client application will certainly be different, based on site-specific business functions it implements and the programming language and application model it uses, ultimately it must perform the same web service functions as the test client application bundled in SAKA. Because the client application focuses only on testing the implementation of the SAKA service, it is ideal for ensuring the correctness of a specific site’s implementation.

The currently supported operations of the DEMO client are:

1. Encrypt simulated credit card numbers.

2. Decrypt the ciphertext for previously encrypted credit card numbers.

3. Encrypt and decrypt a credit card number within a single transaction.

4. Delete a credit card number from the cluster.

5. Search for a credit card number on the cluster.

6. Return bytes of entropy from the SAKA Cryptomodule.

7. Submit a job to encrypt credit card numbers, in batch mode.

8. Submit a job to decrypt credit card numbers, in batch mode.

9. Submit a job to delete credit card numbers, in batch mode.

10. Submit a job to search for credit card numbers, in batch mode.

11. Relay a payment transaction to authorize.net using HTTP POST (requires the site’s own account and access keys to authorize.net to perform this test).

The client application distinguishes between these operations to allow sites to test different levels of authorization for the web services:

1. Users who are authorized to only encrypt.

2. Users who are authorized to only decrypt.

3. Users who are authorized to encrypt and decrypt.

4. Users who are authorized to only delete.

5. Users who are authorized to only search.

6. Users who are authorized to only relay transaction to a payment gateway.

7. Users who are authorized to perform all operations.

8. Users who are NOT authorized to perform any operation.