Protecting Resources

Some REST API actions can lead to destructive outcomes. For example:

>HSM zeroization: all partitions and cryptographic material is destroyed

>Applying destructive policy settings: all cryptographic material is destroyed

>Exceeding last login attempt: all cryptographic material is destroyed

>Applying destructive HSM capability update: all cryptographic material is destroyed

To provide an application with a measure of control over these kind of actions, the REST API has a process to protect destructive resources. This two-step process is as follows:

1.The application requests the destructive resource. This action creates a suspended (WAITING) task.

2.The application kick-starts the task so that it can run and complete the destructive process.

An application performs the kick-start via a task actions resource called start as shown by the following prototype:

POST
https://LUNAIPADDRESS:PORT/tasks/{taskid}/actions/start

Additionally, the REST API has another resource to list all task actions:

GET
https://LUNAIPADDRESS:PORT/tasks/{taskid}/actions

Example: The following example describes the steps required to zeroize the HSM:

1.Log in to REST.

2.Log in to HSM as SO.

3.POST /api/lunasa/hsms/{hsmid}/actions/zeroize

Returned is a task object referenced by /tasks/{taskid}

4.GET /tasks/{taskid} and confirm the task is in WAITING (suspended) state.

5.POST /tasks/{taskid}/actions/{actionid} to continue the zeroization.

6.GET /tasks/{taskid} to confirm the task is in FINISHED or ERROR state.

7.GET /tasks/{taskid}/response to obtain the output of the zeroization resource.