Overview

SWF can either be used with the primary server (web UI), or with the automation REST API that will run alongside it. The automation API can be used to automate the creation of tasks, in order to create custom flows and integrate the functionality of SWF into your overall system.

Examples:

  • Automate the flow of signing parking permits to citizens
  • Automate the signing process of contracts

 

To enable this, set `automationApiEnabled` to `true`. The UI will be running on port `8080` and the automation API on `8081`. If you want to update these ports, you can do that by setting these parameters in your `config.json`:

{
  "primaryServerPort": 8080,
  "automationApiEnabled": true,
  "automationApiPort": 8081
}
Click to copy
  • primaryServerPort - The SWF frontend server port
  • automationApiEnabled - Whether the automation API is enabled
  • automationApiPort - The automation API server port

Both these endpoints use the same underlying infrastructure and functionality, but they are designed differently to support
different needs. The primary servers are there to support the SWF UI, and the automation API is there to support
other services in your overall infrastructure.

The SWF UI endpoints, available under the configured primaryServerPort, are subject to change between versions, but the
current version of the UI API can be seen here.

Understanding the signature data flow

When signing a file, the data will flow from SWF to PAS, which will generate the signature and add it to the file. After the signature has been added, PAS will publish the file to SWF that will fetch it and store it in its database. The detailed flow works as follows:

  1. The user initiates the signature by pressing View and Sign in the UI.
  2. The frontend will perform a POST request to the backend which will:
    1. Validate the user
    2. Upload the file to PAS. The uploaded file will be a base64-encoded JSON array. Each item in the array will look as follows:
      1. id - The SWF file ID
      2. fileName - The name of the file
      3. toBeSigned - Whether the file is to be signed
      4. content - the base64 encoded byte array of the file
    3. Generate a JWT
    4. Place the JWT in a URL
    5. Redirect the user to PAS via the URL generated in the previous step
  3. The user gets redirected to PAS, that will:
    1. Authenticate using the JWT. The JWT will include the following parameters:
      1. id
      2. successURL
      3. failURL
      4. cancelURL
      5. tenantId
      6. userId
      7. userMobile
      8. userMail
      9. userSource
    2. Show a preview of the file using the PrismFedSigning module.
  4. The user will review the file contents and when all is reviewed, press one of these buttons:
    1. Cancel - The user will be redirected to the cancelURL found in the JWT
    2. Sign - The user will call the authentication redirect URL (sign_auth_redirect_url in the PrismFedSigning config)
      1. The user will sign/authenticate using the configured IdP
      2. When the IdP has signed/authenticated, the user will be redirected to the /sign endpoint in the PrismFedSigning module
      3. PAS runs the configured sign pipe. The signed file should replace the non-signed file in content in each item of the array uploaded from SWF.
      4. PAS adds the signature ID to the URL and redirects the user back to SWF
  5. SWF receives the redirect request and uses the signature ID to download the file from PAS.
  6. If the file has been updated, and the file that was originally sent to PAS is the active file, the file is stored.
  7. SWF updates the users that should sign next
  8. The sign action is successful