SCIM: The request contains invalid parameters or values

Hi Chrysoula,

maybe there is a special scope  and / or authorization type need. Have you tried both options of "grant type" configuration (client or password credentials)?

regards,

TIno

Hi Tino, yes. We tried various scopes, but we still cannot achieve a connection in the Sync Editor.

What kind of SCIM  provider do you try to contact (product)?

We are trying to reach Oracle Identity Cloud Service if this is what you are asking for.

OK, do you have the ability to trace the connection using Fiddler?

We did a trace and we found out that there is something wrong with the ciphers. Postman uses a chipher that it isn't recognized by One Identity. It loks like it reverts to a certificate based connection. We will raise a SR.

Differences in new IDCS connection - UAT - PostMan and OI.zip

Hi tlindner  we don't have fiddler but I was able to do a WireShark trace ..... see attached.  

We can see that when postman does it’s connection it has a list of 18 ciphers to choose from and we can see that it does a change cipher and chooses TLS_AES_256_GCM_SHA384 for the connection and it’s all good.

We can see that OI has a list of 8 ciphers to choose from ….. which do not include TLS_AES_256_GCM_SHA384 so it looks like it reverts to a certificate based connection. We do get a “Server Hello Done” message but I don’t know if this means that it has really made a connection and worked …. I suspect not as we get an ‘unauthorized’ message in the connection wizard.

Next thing to understand is why PostMan has way more ciphers than OI and why OI falls back to a certificate based connection and if we can make the cert connection work by installing a cert.

Does this help?

Thanks, Barry (working with Chrysoula on this)

Differences in new IDCS connection - UAT - PostMan and OI.zip

Hi tlindner  we don't have fiddler but I was able to do a WireShark trace ..... see attached.  

We can see that when postman does it’s connection it has a list of 18 ciphers to choose from and we can see that it does a change cipher and chooses TLS_AES_256_GCM_SHA384 for the connection and it’s all good.

We can see that OI has a list of 8 ciphers to choose from ….. which do not include TLS_AES_256_GCM_SHA384 so it looks like it reverts to a certificate based connection. We do get a “Server Hello Done” message but I don’t know if this means that it has really made a connection and worked …. I suspect not as we get an ‘unauthorized’ message in the connection wizard.

Next thing to understand is why PostMan has way more ciphers than OI and why OI falls back to a certificate based connection and if we can make the cert connection work by installing a cert.

Does this help?

Thanks, Barry (working with Chrysoula on this)

Hi Barry,

If I recall correctly, in .net framework ciphers are managed by the OS.
Does this powershell command return the cipher?

Get-TlsCipherSuite -Name "TLS_AES_256_GCM_SHA38"

Hello Andreas, I tried to run this PowerShell command in our environment where the SCIM conenctor is running, but I get no results.

Hi Barry,

the Cipher suite TLS_AES_256_GCM_SHA384 is part of TLS 1.3 protocol which is explicit allowed to use in SCIM connector since OneIM 9.0 as transport encryption. As Andreas statet the underlying .NET framework has to handle the negotiation and transport encryption with the server. That's nothing inside OneIM.

I think a switch over to certificate based authentication will not work as long as we are talking about transport layer encryption. The handover of certificate also needs a secured TLS channel.

Could you check the installed version of .NET Framework? If it is not 4.8 please update it.

Regards,

   Tino

Hello Tino, we support Windows Server 2019 in our environments. We did a check and this does not support TLS 1.3 version. However, we have the .NET 4.8 framework installed. 

Hi Chrysoula,

this explains the fallback to TLS 1.2 protocol shown in the trace. This is usual negotiation behavior and as far as I can see not the root cause of your issue. Is your test situation the "Test" button in SCIM connection wizard?  Will this return the HTTP 400? Could you trace this HTTPS traffic using Fiddler? Is it possible to see some more information at Oracle side?

regards,

  Tino

Hi Chrysoula,

according the Oracle documentation (https://docs.oracle.com/en/cloud/paas/identity-cloud/rest-api/OATOAuthClientWebApp.html ) you have to configure the scope value "urn:opc:idm:__myscopes__". Have you tried this?

Hello Tino, it seems that the supported TLS cipher for Oracle Identity Cloud Services system is installed in our environments. And yes, we are using the correct scope in One Identity (myscopes). Supported TLS Cipher-Suites (oracle.com)

Hi Chrysoula,

I would rule out some copy / paste errors and some possible issues during changing a connection configuration with creating a new connection configuration. To be sure to "Authorization" header has the correct value I would do the encoding of authorization string used by OAuth 2.0 myself as follows:

concatenate  <client Id> ":" <client secret> and let encode this string as Base64 (use the website https://www.base64encode.org)

Put the result into "authorization string (base64)" field. Set the scope to "client based" and configure the value "urn:opc:idm:__myscopes__". Test this configuration.

If the result is same error you should consult the Oracle admin to have a look at the access logs to find out which parameter is faulty.

Regards,

Tino

Hi tlindner ,  thanks for all your help with this.  Looks like we have found the solution.  We had all the right values, just not necessarily in the right place!  After some trial and error, we found we had to put the Client ID in the User name field (not the Application / Client ID field as you would expect) and the Client secret had to go in the Password field (not the Client Secret field as you would expect).  After that we were able to connect and browse the target.  Regards, Barry.