View your application’s Service Credentials under the “Service Credentials” link in the application’s navigation. This displays a list of all of your application’s Service Credentials, including each credential’s type.
Click a credential from the list to view its configuration, make edits, or view its usage across your application.
From the Service Credentials list page, click “Add Service Credential” in the top right corner. On the next screen, choose which type of credential to create, with the type corresponding to the cloud service provider or third-party API whose services you are connecting with your application. The type cannot be changed after the credential is created.
Once you have selected a credential type, fill out the following fields on the next screen:
- Name: The name of the Service Credential. This field is required, and it must be unique within your application.
- Enabled: A checkbox indicating if the credential is enabled. Unchecking this box will retain the credential within your application, but any attempted uses of it will fail. New credentials are enabled by default.
- Description: Allows for a longer description of the credential and its intended use. This field is optional.
Each credential type requires additional fields that must be filled out.
- AWS Region: The AWS region where the services the credential is accessing are hosted.
- Access Key ID: The ID associated with the IAM access key.
- Access Key Secret: The secret portion of the access key. This value cannot be retrieved after creating or updating the credential.
A Microsoft Azure credential takes the following information, which can be found in the Azure service’s interface:
- Account Name: The name of the account associated with the token. This field is optional; however, most Azure services require this value so it should be provided for the majority of use cases.
- Account Key: The token used to authenticate the request. This value cannot be retrieved after creating or updating the credential.
A Google Cloud Platform credential takes a Service Account Key, which is a JSON object containing several properties. When updating this value in the future, the entire account key object must be included in the request.
private_key property is redacted after creation and updates and cannot be retrieved.
An HTTP credential can be used to authenticate requests made through the HTTP Node. It takes the following information:
- Credential URI: The URI that the credential will be allowed to make requests to. Sub-paths and query parameters may be provided in the HTTP Node configuration. If updating this value after creating the credential, you must also provide the authentication info as part of the request to prevent unauthorized access to the credential.
Authentication Method: The method for authenticating the node’s request; the method you choose depends on what is accepted by the service you are making the request to …
- HTTP header: Appends the provided header name and value to the request. The header value can be updated but not retrieved after creating the credential.
- Query parameter: Appends the provided query parameter name and value to the request. The query parameter value can be updated but not retrieved after creating the credential.
- Basic (username and password): Attaches the provided username (optional) and password to the request through the Authorization header. The password can be updated but not retrieved after creating the credential.
- Client certificate: Adds the provided client certificate and client certificate key to the request. The client certificate key can be updated but not retrieved after creating the credential.
- API Key: The SendGrid API Key used to authenticate the request. This value cannot be retrieved after creating or updating the credential.
- Account SID: The unique ID associated with your Twilio account. This value always starts with “AC”.
- API Key SID: The SID of the API key to authenticate with. This value always starts with “SK”.
- API Key Secret: The secret value associated with the provided API Key SID. This value cannot be retrieved after creating or updating the credential.
Service Credentials can be used to authenticate against any of the major cloud provider services that have first-class support in the Losant platform, as well as third-party APIs that can be accessed through the HTTP Node.
Losant’s real-time, bi-directional integrations to Amazon SQS, Azure Event Hubs, and Google Pub/Sub can all use Service Credentials to authenticate their connections to those services. In some cases, utilizing a credential may require additional settings in the integration configuration.
Note: When updating a Service Credential, any integrations that reference the credential for authentication will automatically reconnect to ensure that they are utilizing the new settings. In the case of invalid connection info – or if the new credential lacks permissions from the cloud vendor to utilize the service - the integration will fail to reconnect.
Service Credentials can be used as an authentication method in any workflow node that connects with a cloud provider’s managed service, such as the AWS: Lambda Node, the Azure: Table Storage Node, or the GCP: BigQuery Node, amongst several others. Third-party APIs that accept authorization through HTTP headers, query parameters, basic authentication, or client certificates can also use Service Credentials to authenticate requests made using the HTTP Node.
Credentials can be selected directly from your application, or they may be referenced by name using a string template.
Service Credentials cannot be used in Edge Workflows; they are only a valid configuration option for nodes used in Application Workflows, Experience Workflows, and Custom Nodes built for those two flow classes.
Daily application archiving also supports Service Credentials as an authentication method for writing data backups to Amazon S3, Azure Blob Storage, and Google Cloud Storage. When using a credential to authenticate, you must still provide the bucket/container name for where to place the daily archive files, and the credential must have permission to write to that bucket.
From a Service Credential’s detail screen, click the “Usage” tab to view any workflows, custom nodes, integrations, or archive configuration where the credential is being used. This helps to track down any application configuration that may need to change if you are editing or deleting the credential.
In the case of workflows and custom nodes, an item will appear in the table if any version of the resource references the credential.
To change the authentication values for a given credential, click the “Make Changes” link within the “Credential Configuration” panel to unlock the populated and redacted inputs. You may then update the values with the new settings from the cloud provider. If the link was clicked in error, you may click “Revert Changes” to discard any updates and return the form to its original state.
Once you are finished, click “Save Service Credential” to commit the updates; any requests to use the credential after this point will reference the new values.
Changing a credential’s name will cause all uses of it to fail. This is because credentials are referenced by name – not by ID – wherever they are used. For this reason, the “Name” field is locked in the user interface to prevent accidental updates; users must click the “Edit” link in the input’s label to unlock it before making any changes.
If you must change a credential’s name, you should first change any usage of the credential to reference the new name before changing the name of the credential.
To protect the integrity of a Service Credential, there are a handful of limitations imposed on their use that developers should keep in mind …
Each credential type has properties that may be set on creation and update, but never retrieved. This is the primary security benefit of using Service Credentials within your application, as this greatly reduces the risk of provider-issued authentication values being leaked to unauthorized users.
When retrieving a credential, information that is not considered sensitive (such as the Access Key ID in AWS, the Account Name in Azure, the Project ID in Google, or the header name or query parameter name in HTTP requests) is still visible; this helps correlate a Losant Service Credential to an authorization resource in the cloud provider’s interface.
As noted above, Service Credentials cannot be utilized in Edge Workflows. This is because the sensitive authentication values would have to be transmitted to the Edge Compute Device for use, and even if they were encrypted at rest, the decryption keys would also be stored on the device – leaving the values retrievable to anybody who gained physical access to the hardware.
Service Credentials are never included in application export bundles. Doing so would expose the credential’s sensitive information in a plain text file that could fall into unauthorized hands. For this reason, any export bundle referencing a credential that is then imported as a new application or into an existing application requires creating a credential of the same name and type within the receiving application. Failing to do so will cause any uses of the credential in the receiving application to fail.
Similarly, Service Credentials are never included in application clones. While the credential’s sensitive information would not be at risk, cloning an organization’s application to a different organization or to a sandbox could allow untracked, unauthorized access to a company’s corporate cloud infrastructure. Therefore, cloned applications also require recreating credentials of the same name and type.
HTTP Service Credentials may only be utilized for the URI specified as part of the credential configuration, or for any sub-path of that URI. This is to prevent malicious users from making an credential-authenticated request to a server under their control, which would allow the user to view the HTTP headers, query parameters, and sensitive authentication information associated with the credential.
To that end, any updates to an HTTP Service Credential that modify the URI property must also include a new secret value (the HTTP header value, query parameter value, password for basic authentication, or client certificate key) to prevent malicious actors from changing the credential to a domain they control.
Finally, any headers or query parameters that are included in a credential-authenticated request will have their values redacted from the HTTP Node’s
request object in any workflow debug output; this prevents their retrieval from the workflow’s debug log.
To delete a Service Credential, click the “Delete” icon next to any item on the list page, or by clicking the “Delete” button in the footer of a credential’s edit page. Doing so will immediately remove the credential from your application, and any attempted uses of the credential within your integrations, workflows, or application archiving will fail.
You may, however, create a new credential of the same name and type, and any uses of the previous credential will automatically use the connection settings provided in the new credential.
Was this page helpful?
Still looking for help? You can also search the Losant Forums or submit your question there.