Share all details about your problem, including any error messages you may have received.
I have a web services connector with operations set for GetObject, Create Account, Add Entitlment, and Reomve Entitlement.
I can add and remove entitlments for users that already exist in the target system. These are handle by submitting access request through the “Manage User Access” function.
The issue occurs when I submit for access for somebody that does not have an account in the target system. The overall process shows as a failure but when I check the target appication it does create the account but does not add the access.
It gives an error that the "The request requires user authentication. Below is part of the error I grabbed from logging.
What I think is the issue and what I have done to try and fix it.
So my assumption is that it needs authentication again when it is attempting to add the usergroup to the newly created user. So I added the Authorization: header and passed in the base64encoded value since we are using basic auth. I have also did these when we switched it to API Token auth type.
I have compared and dont see any difference between access request for user with out an account in target application VS access request for a user that has an account already in target applicaiton.
The only difference of course is that one is trying to do multiple API calls (Create Account, Add Entitlment). Where the other is just single API call for Add Entitlment.
@Arpitha1 I’m not certain whether this API supports performing both operations within a single request. However, I have already tested setting "createAccountWithEntReq" to true, and the issue persists. The account is successfully created, but the subsequent GetObject call fails with the same error. Additionally, the entitlement is not assigned to the user.
Logging is currently enabled at the TRACE level. Could you clarify which specific log statement contains the request payload?
@paul_hilchey Each operation does have the authorizztion header. But seems like that it is not passing in during the calls.
I did take the URL from the payload that it used in the getObject operation. I posted that in a web browser and it does a popup window asking for username and password and verified what we are using works.
So in the authoratzation header I am passing Basic type as a base64 encoded username:password. But that does help either.
I created before rule to capture the request end point details. See info below. This is what log from submitting a single access request for a user that does not exist in the target system. I shows 3 operations being completed Create User, Add Entitlement, and Get Object. The whole process errors out as stated in my orginal post but the user does get created.
It looks like the auth headers are being passed each time but it fails with 401 Unauthorized “This request requrires user authorazation”.
Yeah seems like Authorization header is getting passed in all 3 operations. Can you take complete value (Basic ) from requestEndPoint and test these in PostMan or in curl, by passing that Autorization header as exactly same as you copied from requestEndPoint.
@Arpitha1 I’ve validated using both cURL and Postman that all operations execute successfully when the Authorization header is passed as currently configured.
As a sanity check, I also modified the value of the Authorization header, which resulted in a failure—confirming that the header is being correctly utilized in the request. I’ve updated all connector operations in SailPoint to use equivalent cURL calls for consistency and re-tested, but the issue persists.
Additionally, I set the createAccountWithEntReq flag to true, but since the target application does not support this operation, the entitlement assignment still fails. Specifically, the failure occurs during the GetObject operation, returning a 401 Unauthorized error.
Do you have any suggestions on how to properly handle this within SailPoint to prevent the failure, especially in scenarios where the account doesn’t yet exist?
I think I have identified the issue as a session-based authentication limitation with the target application’s API. SailPoint is not correctly managing the session cookie across multiple provisioning operations.
The API creates a session on the first call and keeps it open for 15 minutes. When SailPoint attempts a second call (e.g., to add an entitlement after account creation), it fails because the API won’t allow a new session while one already exists—it expects the original session cookie to be reused.
I validated this using cURL by saving the cookie with -c cookie.txt on the first call and reusing it with -b cookie.txt on the second, which works. However, when I try to replicate this in SailPoint, the connector doesn’t throw an error but also doesn’t complete the account creation. If I remove the -c flag, it works, confirming the session is mishandled.
I’m looking for guidance on how to capture and reuse the session cookie across multiple API calls within SailPoint—ideally using rules like AfterOperation to persist and inject the cookie into subsequent requests.