The Java PSDK does not work correctly for the SCIM query API

[liebichw]

I tried to use the SCIM API to fetch a list of groups with the SCIM API. I also tried to support filtering out specific attributes, by passing an attribute list into the getter (https://developer.genesys.cloud/useragentman/scim/scim-apis#get-api-v2-scim-v2-groups).
As soon as I pass more than 1 attribute in the attribute list, the query does no longer restrict the attributes!

EDIT: This problem also occurs when querying users via SCIM.

EDIT: The same problem occurs with the "GET users" API.

The JavaScript PSDK, on the other hand, constructs an acceptable URL for SCIM group queries - so this problem is not universal to all Platform SDKs.
After some experiments (with cURL) I found out that the problem lies in the way the Java PSDK generates the URL for the query:

• When using the API explorer to generate a query, the query URL looks this way: https://api.mypurecloud.de/api/v2/scim/v2/groups?attributes=displayName&attributes=members - so the list of wanted attributes is encoded as 1 query parameter, with the values separated by ",". This query works as intended.
• If I pass, for example, "displayName" and "members" in the "attributes" list, the Java PSDK API generates following URL: https://api.mypurecloud.de/api/v2/scim/v2/groups?attributes=displayName&attributes=members - as you can see, the "attributes"-parameter is present more than once. The HTTP standard allows this, but this query does not work as intended - the members are not present in the output.

So this is either a bug in the backend which mis-handles multiple instances of the same list-valued query-parameter, or in the Java PSDK which encodes a list-valued API parameter the wrong way.
Either way - it is not possible to use the Java PSDK to restrict attributes in a SCIM query.
Is this solved in a new PSDK version, or should this be solved in a new backend version?

[liebichw]

The same problem occurs when querying users via SCIM in the JAVA API.

The JavaScript PSDK, on the other hand, will construct a query URL which is acceptable for the backend, i.e. it will use the "attributes=<att 1>,<att 2>" form of specifying multiple values as a list.

[John_Carnell]

@liebichw

problem is not universal to all Platform SDKs.
After some experiments (with cURL) I found out that the problem lies in the way the Java PSDK generates the URL for the query:

Hi,

Thanks for posting and Happy New Year and thanks for the great writeup. You do not know how much appreciate this additional level of detail. I am going to open a ticket with my team and have them investigate. I will ask them to respond once we have done out investigation. Just be aware that we are just ramping up from the Holiday break and finishing up a Sprint so this might not be gotten right away.

A quick analysis seems to be that this is related to how we are building our query params. If you are blocked on this you might have to call the API endpoint directly until we get this resolved.

Thanks,
John Carnell
Director, Developer Engagement

Thanks,

[liebichw]

Happy new year to you, too - thanks for your quick reply!
I looked into the PSDK code - yes, it has to do how the query params are built, correct - the code just uses a standard method to convert a value list to params, which is to use multiple occurrences of the parameter.
In the JavaScript PSDK this is done the same way, btw - but in this case, it seems that another library (axios?) is doing The Right Thing.

[John_Carnell]

Hi liebich,

I just talked with the SDK team. The issue is that our service APIs are supposed to support both a comma-separated approach and attributes with the same name. When we generate the SDKs we pick one of the two ways to build the list. Hence the difference between the Java SDK and the Javascript SDK. I am going to open a ticket with the service team and see if they can make sure the service supports both methods.

Thanks,
John

[John_Carnell]

Hi liebich,

Just a quick update. The team wrote the service exactly to the SCIM spec ( RFC 7644 - System for Cross-domain Identity Management: Protocol) as usually the SCIM APIs are called directly from LDAP using the REST APIs.

When we generate our SDKs we ask the API teams to support both methods of query parameter resolution and we pick one method to use in our language generation process.

1. I have asked the service team to add the capability to handle both query parameter methods to the service but it will not be a trivial task.

2. I have asked my SDK team to see if we can mitigate this but we are still scoping out the work and we have to make sure we don't introduce regressions that could impact more than this method

3. If you are blocked I would recommend you directly call the REST endpoint instead of using the SDK for this specific API. Our SDKs are very light wrappers around this endpoint so calling the endpoint directly while a little more painful is still very doable.

Thanks,
John Carnell
Director, Developer Engagmeent

[Jerome.Saint-Marc]

Hello,

We have tried to introduce a change in the SCIM Api of the latest Java SDK (version 218.0.0) so the values of the array attribute are sent in csv format (comma separated) instead of multiple attributes.
Let us know if that works and solves your issue.

Regards,

[liebichw]

OK, thanks, now the Java PSDK builts correctly formatted queries, I can confirm that. Sufficient for us now.