Managing Responses in Workflows
Response Management: Handling Feedback and Completing Workflows
Once a target system has received a workflow notification from Next Identity, a response is expected to prevent a retry or a logged failure. In the case of synchronous actions, a response is needed to proceed with the user workflow.
Responses are always expected to return a200 OK HTTP response code. If the system receives an invalid URL response, it will be logged as a failure and will not be retried. HTTP error responses will be retried. Any other response that is not a 2XX response or one of the above will be marked as a failure and will not be retried.
In the case of asynchronous enrich actions, where a response message is needed to determine the next steps for the user workflow, the response to the Next Identity workflows service is expected to contain a signed JWT in the body with the necessary information to proceed. When configuring a receiving endpoint for workflows, the JWS source must be provided to the configuration team to decode the JWT.
A sample payload response for an enrich action from the target system back to the Next Identity Workflows service might look like this after the JWT is decoded:
{
"iss": "https://system.example.com",
"iat": 1458496025,
"jti": "someuniqueeventidfb4e75b5411e4e19b6c0f",
"action": "allow",
"custom_claims": {
"some_key1": "some_value1",
"some_key2": "some_value2"
}
}
Target System Response Message Components
| Attribute | Description | Required | Value Restrictions |
|---|---|---|---|
action | What action should Next Identity take with this transaction? This should be from the customer system based on whatever processing was done based on the original Next Identity notification for this transaction. | ✅ | Accepted values allowed are:allow: The user can proceedblock: The user should be blockedchallenge: The user should be provided a security challenge |
custom_claims | Claims from an external service that are included in the id_token for the user at the end of the login process | ❌ | This is appended to the id_token as is and does not go through any validation or changes in the service. |
iss | Service provider publishing the SET | ✅ | None |
iat | Issued at dateTime | ❌ | None |
jti | Unique ID of the event | ❌ | None |
How to configure Workflows?
Workflows are configured by Next Reason. Contact your Next Reason Solutions Architect to discuss your workflow requirements.
Updated 12 months ago