I am currently working on a Web Services VA-based connector and encountering the following issues:
I am using custom authentication, where I receive a sessionID in the response. This sessionID needs to be reused to authenticate subsequent endpoint calls.
When testing in Postman, the “Get All Users” API returns the expected response. However, within SailPoint, the results are not as expected.
During account aggregation, I have implemented Before and After rules for pagination. The issue is that a new sessionID is being generated for each request, instead of reusing the existing session.
Additional Information:
Maximum number of concurrent logins allowed for the service account: 10
Default session timeout for a single API login: 60 minutes
Could you please assist in identifying the root cause and suggest a solution?
I don’t know what your configuration looks like, but for me, custom authentication requires the authentication type to be set to “Custom Authentication”, and an HTTP operation with operation type “Custom Authentication”. Then you store the response, sessionID in this case, so that it can be reused in the remaining requests, using response mapping or an afterOperation rule. Finally, under Additional Settings, fill in any necessary errors so that ISC knows when to re-auth. For example:
The point within an operation that custom authentication is triggered may vary depending on the operation you configure.
When performing a Test Connection, the system first executes the custom authentication operation or endpoint. This step is important as it retrieves the customaccesstoken or other authentication-related attributes, which are then utilized in the headers or body of the Test Connection operation.
For other operations, the system first verifies whether the customaccesstoken or any related authentication attributes are saved. If they are, it utilizes them. If not, it executes the custom authentication operation or endpoint to generate the customaccesstoken or any related authentication attributes.
If an operation fails, the system checks the returned exception code. If the code is 401 or if the error code/message matches one is configured in the HTTP Error field on the Additional Settings menu page, it triggers a custom authentication operation or endpoint. This process generates a customaccesstoken or any related authentication attributes. For more information on the HTTP Error field, refer to HTTP Errors.
by default, the connector only gets the new session every time for test connection op and other ops reuse unless you configure the error msg explicitly to catch it and get new session.
can you post your custom auth config and also curious about the rules for pagination. if you can post the rule.
The issue was resolved by passing the Session ID in the request headers before the operation rule executes and then using that same Session ID in the after-operation rule to properly close the session for each HTTP call.
But Accounts Scanned showing more than actual accounts.
I would suspect something with your before and after rules, if the object count has changed that much.
Back to your API always returning a 200 response code, doesn’t it still provide a message in the response that your not authenticated? You just need to make sure that message is configured in the Additional Settings page. @lampard08 posted the link to the relevant doc.
Also, as @BBR1 mentioned, you need to be checking your VA logs to see what exactly is happening before, during, and after each of the configured HTTP operations. I like to use something like this to more easily navigate the VA logs:
The $1 and $2 are just placeholders for source name and timestamp, but you can filter on anything you like. The jq makes the json more readable. Using less makes the output scrollable/searchable. When you are using less, the -R helps to preserve the formatting the jq provides.
