Share all details about your problem, including any error messages you may have received.
Hey everyone, i’m working through onboarding an application in IdentityIQ 8.4p2. This application was originally going to be onboarded as a SCIM 2.0 application. However, after getting through some of the application configuration we found out that the app isn’t 100% SCIM compliant.
I had to convert this application to a Web Services connector and with the help of ES we got the application converted - for the most part. There is a before rule that has to be used so that the application can assert the authorization bearer token and decrypt it. This allows for the application to connect back to the API.
While I can do a successful group aggregation, account aggregation and get all the accounts correlated i’m having troubles with entitlements.
Anytime I ATTEMPT to add an entitlement via the manage users page, or anytime I ATTEMPT to remove an entitlement I am getting the above 405 errors. I’m not quite sure what i’m doing incorrectly or why i’m getting the errors at all. I have removed the before rule even and attempted and still get the errors.. Any help would be greatly appreciated.
Also, these entitlements are not tied to roles within IdentityIQ. They are stand alone entitlements and the operations i’m using in IdentityIQ I can successfully use in Postman..
HTTP 405 means the HTTP method (PATCH in your instance) is not allowed/supported against the /groups endpoint. Check the API docs to see if it needs to be something different like a PUT.
That’s been part of my confusion because the PATCH method is the only one defined by the application as being able to do the operation i’m attempting to do…
PATCH /v2/groups/[id]
Update a group. You can update the group/role displayName or members. You cannot update both the displayName and members in the same request, they must be different requests.
Your context URL does not seem properly configured then. You would need something like /groups/$plan.groups$ to hit the endpoint for the specific group being provisioned for the user.
I don’t really have enough info to help you out more here at the moment. I’d have to see API documentation and more of your configuration on the HTTP body you are sending. In general, this error now probably means you are not sending the expected payload, or it’s malformed.
@MRP4ND4 Have you tested the APIs using Postman? Could you please share the sample add entitlement request and response?
Please print the object: requestEndpoint in your add entitlement endpoint’s before rule. Compare the config(body, operation, headers, params, url,etc) with the one you have in postman. This should be able to tell you if there is a mismatch between IIQ vs Postman.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
Error 405 means the http method you are using is not allowed and not supported for the url you are using. Please check the api documentation for correct http method details
yeah, everything i’m doing works through postman. It’s just not working in IIQ for some reason.. I’m using the same http method in postman as I am in IIQ
@MRP4ND4 In your add entitlement endpoint, add a before rule (if not already) → print requestEndpoint object : log.error(“requestEndpoint::”+ requestEndpoint). → check logs, and validate the value.
As you confirmed, it is working in postman. Check the logs and compare the config against postman for any discrepency. If you need any help, please ping me over chat, and we can get into a working session.
Please share the API document here or please check if all the input variables have the values as expected by API. You may be passing the variables from Plan but the variables may not have values or values are not as expected.
The issue with PATCH requests to /v2/groups/[id] return an HTTP 405 Method Not Allowed error in SailPoint IIQ but work in Postman—is a common configuration hurdle. This error indicates that the target server is rejecting the PATCH method, often due to a mismatch in headers, URL construction, or how the Web Service Connector handles the request.
Verify and Update Headers - Ensure your “Add Entitlement” and “Remove Entitlement” operations have the following headers:
•Content-Type: application/json-patch+json (Try this if application/json fails).
•Accept: application/json
Ensure the Context URL for your update operations is targeting the specific resource ID.
•Correct Format: /v2/groups/$plan.nativeIdentity$ or /v2/groups/$left.id$
•Verification: Check the SailPoint logs (sailpoint.tools.HttpClient) to see the exact URL being called. If it ends in /groups/ without an ID, that is the cause of the 405.
Match the JSON Patch Payload - If the API expects a JSON Patch format (common for PATCH methods), your body must be an array of operations, not a standard JSON object.
•Postman Working Payload: [{"op": "add", "path": "/members", "value": [{"value": "user_id"}]}]
Check for “Hidden” Redirects - If the API URL has changed from http to https, or from api.v1 to api.v2, the server might send a redirect. SailPoint’s connector might follow the redirect but “downgrade” the PATCH to a GET, resulting in a 405.
•Fix: Ensure the Base URL in the application configuration is the final, absolute URL (including https ).
This is fairly close to the solution we had to use. The SCIM API from the vendor wasn’t 100% SCIM compliant and thus we had to change from the SCIM connector to the Web Services connector. While the headers did need to be correct, there was also issues with how the payload was being sent from IIQ to the vendor’s endpoint. In the before rule we had to transform the payload and ensure it was sent from IIQ the way the vendor expected it. Otherwise, if the payload was sent in the wrong format it would fail.
This took rebuilding the enstire context url and pasing json. Right now the add and remove entitlements is working as expected after rebuilding the before rule and making it work. ES helped build this out for me after several sessions of TS. It was quite troublesome…
,
, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.