VIP AuthHub | Push Auth with custom SPI not working

Products

• VIP Authentication Hub

Issue/Introduction

Push Authentication is not working with Custom SPI 

Also transaction id is getting changed while calling PushStatus api, its not having same transaction id which was passed while calling PushMessageSender api.

 

 

 

Environment

Release : OCT 23 Release

Resolution

confirmed that PushContext is behaving correctly as per https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/vip-authentication-hub/2022-Oct/Developer-Information/integrating-with-Custom-SPI/Integrating-with-External-Push-Provider.html - the same PushContext returned by your PushMessageSender SPI is being passed into your PushStatus SPI.

Please make sure that whatever lookup you're implementing in your PushStatus SPI uses the data from, and only from, PushContext that is being passed into your PushStatus SPI.

You must not rely on any other identifiers, such as transactionId passed in via the AH context (that transaction id was indeed fixed to be unique per request).

Please note that the keys in PushContext as returned by your PushMessageSender SPI implementation, and consumed by your PushStatus SPI implementation, are neither visible to nor understood by AH. Its up to your implementation to construct and name these keys as you see fit.

The AuthHub Document for OCT Release 2022 happens to give an example of PushContext using the below keys.  Going forward, this example will replace "key": "transactionId" by "key": "pushRequestId" to avoid possible confusion.

  "pushContext": [
    {
      "key": "transactionId",
      "value": "txnId-6hdds733"
    },
    {
      "key": "deviceId",
      "value": "device-hdyn235sd"
    }
  ],

 

Regarding Transaction ID - each request into AH results in the response having a *unique* transaction ID returned, as TransactionID identifiers are unique allowing each AH request to be troubleshooted.

To track a group of client requests under the *same* correlation id, please have your signin client generate a GUID at the beginning of the signin flow, and then pass in X-CLIENT-TRANSACTION-ID header with that value when making AH API requests. This ensures that logs and audit trail have the same common identifier covering the signin flow. Also, the response will contain X-CLIENT-TRANSACTION-ID header, if one was passed into the request.

Additionally for tracking/troubleshooting purposes, all the API requests within a single "flow state" are given a common "flowStateId" identifier tracked in the log and audit trail. Currently as of the latest release, this identifier is only for the logs/audit trail, and it is not returned as a header in the response to an AH API request.

For additional info, please see https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/vip-authentication-hub/2022-Oct/Using/use-a-custom-signin-ui-application.html

A bit more about the flow with the custom signin app where X-CLIENT-TRANSACTION-ID is used - there are 2 ways for the signin client to use this ID:

1. When the OpenID RP (your business app) invokes /authorize, it has the option to pass in the correlation id in the form of X-CLIENT-TRANSACTION-ID query string parameter, enabling your custom signin client to use that id. This approach is best for end to end troubleshooting as it associates the business app's log, signin app's log, and AH log.

a) Business app requests authentication from AH:  https://{{sspHost}}/{{apiPathTenant}}/oauth2/v1/authorize?scope=openid&client_id={{clientId}}&response_type=code&redirect_uri=https://www.example.com&X-CLIENT-TRANSACTION-ID=clientTxnId12345&state=mystate

b) AH redirects to the custom signin app:  https://{{custom-flow-url}}/?x-flow-state=cldhdDVGbTE0VEFaakN0KzdodlV1Uk9CVjhZUjJ5TkVXd3pnSDJLNHdBQkZESlZMNnpFRTM1TURYYkJTWHVHSXl3Z0ZnN2lDOUtrMURvV3FyL3ppcitOLzF2UXBmTmZFYUR6R25mN05DNnFYaFg5V3d2U2prT01xd3V5c1ZmakJ5TW9Bcmo5SHN6YjZjcnBvTkd0SEJKSnFkZGpWdXFHZnREbUV3SnhOa1N1Mk80ZEJPMEN6TlpYVjZoOGd2dXp3ZkVlYXVuTk1xWUNwajRBRzRNQUdqZz09&x-service-baseurl=https://{{sspHost}}/{{apiPathTenant}}&X-CLIENT-TRANSACTION-ID=clientTxnId12345

Your custom signin app passes X-CLIENT-TRANSACTION-ID=clientTxnId12345 header when making AH REST API calls.

 

2. If the business app (RP) does not generate and pass X-CLIENT-TRANSACTION-ID query string parameter into /authorize, then your custom signin client will not be given this value during the redirect (as shown above in step 1.b). In that case, your custom signin app should allocate a GUID once before initiating a flow via /authenticate, and pass this GUID into every AH API made during the signin flow.

 

In both options, once your custom signin app gets control it would temporarily save the GUID (received during initial redirect or created on the fly otherwise) so the GUID can be reused during the entire signin flow.