Connector returns truncated access_token from token URL

[whoiscjay (Chris Jones)]

Which IIQ version are you inquiring about?

Version 8.X

Share all details related to your problem, including any error messages you may have received.

Hi team,

Wondering if anyone has experienced this / seen this before.

I am running IIQ 8.4p1 on a tomcat instance, and I am attempting to set-up an application with CyberArk using the PAM connector (based on SCIM), using OAuth2.0 client credentials grant type. When executing a Test Connection, I can see from enabling some http logs that the access_token returned from the Token URL appears to be truncated. I can see this because the length of the access_token is 830 characters, whereas if I return an access_token using Postman, it is 850 characters.

Subsequent calls to the /ResourceTypes endpoint made during the Test Connection are then failing, as the access_token used is not authorised to access this endpoint. If I try use the access token returned that is 830 chars within Postman submitting the same call to the /ResourceTypes endpoint, it returns the same error that I see in my http logs (which is a 401 error). If I use the access_token returned using Postman for a subsequent call to /ResourceTypes, it works.

Could there be any settings within IIQ or tomcat that could result in the HTTP response being truncated?

Thanks,
Chris

[703hardik (Hardik Sharma)]

Hi @whoiscjay,

I researched about this and there might be a problem with missing “maxHttpHeaderSize” in server.xml file found at “apache-tomcat\conf\server.xml”.

you can look at the detailed documentation regarding HTTP connector which tomcat uses inside your tomcat folder at “apache-tomcat/webapps/docs/config/http.html”

I would suggest adding these parameters and restarting tomcat(revert back to normal settings if this doesn’t work)

maxHttpHeaderSize= "10000"
maxParameterCount="10000"

in the key shown in the image.

Go for higher values for these parameters if this doesn’t work also refer to the documentation I mentioned before implementing.

Please let me know if it works…

[whoiscjay (Chris Jones)]

Hey @703hardik ,

Thanks for doing abit of research on this.

I had maxParameterCount set in the server.xml already (set to a value of 10000), however I did not have maxHttpHeaderSize set. From reading the documentation, the default value is set to 8192 - see source).

The maxHttpHeaderSize parameter also sets the default value for maxHttpRequestHeaderSize and maxHttpResponseHeaderSize, so I ended up setting the below in my server.xml file:

maxHttpHeaderSize="65536"
maxParameterCount="10000"

Unfortunately this has not fixed the problem, and I can still see the access_token being set in the Authorisation request header with 830 chars.

When retrieving the access_token from the /oauth2/token/scim endpoint, the access_token is returned within the response body, not the response headers, and the above parameters set in the server.xml are related to the request/response headers.

Example response returned by connector when calling /oauth2/token/scim endpoint:

{"access_token":"TOKEN","token_type":"Bearer","expires_in":18000}

where TOKEN is 830 characters long

Example response returned by postman when calling /oauth2/token/scim endpoint:

{"access_token":"TOKEN","token_type":"Bearer","expires_in":18000,"scope":"scim"}

where TOKEN is 850 characters long, and a scope parameter is also returned.

Looking at the request body sent by the connector, it does not set the scope parameter which is potentially the root cause here.

2024-06-07T02:28:28,929 DEBUG https-openssl-nio-8080-exec-9 org.apache.http.wire:87 - http-outgoing-12 >> "grant_type=client_credentials&client_secret=CLIENT_SECRET&client_id=CLIENT_ID"

If I remove the “scope” parameter from the call in Postman, I now receive an access_token that is 830 chars, similar to what the connector is receiving.

So I think the root cause is that the “scope” parameter is not being set in the request body by the connector when calling the /oauth2/token/scim endpoint. I can’t see any configuration to allow the scope parameter to be set in the request body, but it does appear to be something that is required by CyberArk’s SCIM implementation.

Chris

[whoiscjay (Chris Jones)]

I was able to resolve this issue by setting the following within the application definition:

      <entry key="oauth_request_parameters">
        <value>
          <Map>
            <entry key="scope" value="scim"/>
          </Map>
        </value>
      </entry>

Found this fix in the comments of the PAM Deployment Guide. https://community.sailpoint.com/t5/IdentityIQ-Articles/Privileged-Account-Management-PAM-Deployment-Guide/ta-p/74627

[derek_putnam]

Thank you for following up with your solution!