Instructions for testing SCIM bridge using SCIM API endpoints do not work when integrating with Google Workspace

[DaazKu]

Under the self-managed-tls section it says:

Traffic from your TLS endpoint should be directed to this port (80, by default)

From my understanding that's wrong. The deployment is configured to work with port 3002: https://github.com/1Password/scim-examples/blob/4b38853c38e03b33997d36e9e4f6ccb3d3737df2/kubernetes/op-scim-deployment.yaml#L22-L24

---

Under the test-the-scim-bridge section we can read:

curl --header "Authorization: Bearer TOKEN_GOES_HERE" https://scim.example.com/Users

Thing is, after using the proper domain name, none of the following work:

• https://scim.example.com/Users
• https://scim.example.com/scim/Users

I'm getting a 404 which is VERY confusing since this is the "verification" step and does not work.

The bridge is working though and everything is syncing properly. https://scim.example.com/ redirects to https://scim.example.com/app/login and works (as expected).

[ag-adampike]

Hey @DaazKu! Thanks for filing this issue.

As you've correctly noted, port 3002 is exposed on the container for receiving plain-text HTTP traffic. For this deployment example, the Pod for SCIM bridge is named http to abstract the value.

However, the Service port for receiving HTTP traffic is also named http and set to 80 to align with the default HTTP traffic port for convenience.

When a Service manifest with these lines uncommented is applied, traffic sent to the http Service port of the load balancer is directed to the http container port.

I hope that helps explain things, but please let me know if you still have questions or concerns.

[ag-adampike]

As for testing the SCIM endpoints, can you share any errors that were returned when you were attempting to test the connection?

[DaazKu]

As for testing the SCIM endpoints, can you share any errors that were returned when you were attempting to test the connection?

As I said, I get a 404.

curl --header "Authorization: Bearer {REDACTED}" https://{REDACTED}/scim/Users
404 page not found

{"level":"debug","version":"2.8.3","build":"208031","application":"op-scim","request_id":"ck4770ns153kgsraliig","remote_addr":"10.11.74.120","status":404,"duration":0.008182,"size":19,"method":"GET","base_url":"{REDACTED}","path":"/scim/Users","time":"2023-09-18T15:57:54Z","message":"HTTP request"}

{"level":"debug","version":"2.8.3","build":"208031","application":"op-scim","request_id":"ck477bns153kgsralit0","remote_addr":"10.11.65.253","status":404,"duration":0.008577,"size":19,"method":"GET","base_url":"{REDACTED}","path":"/Users","time":"2023-09-18T15:58:38Z","message":"HTTP request"}

[DaazKu]

Hey @DaazKu! Thanks for filing this issue.

As you've correctly noted, port 3002 is exposed on the container for receiving plain-text HTTP traffic. For this deployment example, the Pod for SCIM bridge is named http to abstract the value.

However, the Service port for receiving HTTP traffic is also named http and set to 80 to align with the default HTTP traffic port for convenience.

When a Service manifest with these lines uncommented is applied, traffic sent to the http Service port of the load balancer is directed to the http container port.

I hope that helps explain things, but please let me know if you still have questions or concerns.

Thanks for the explanation! I re-read everything and it's clearer on that side.

[ag-adampike]

As I said, I get a 404.

So you did, my bad. 🙃

curl --header "Authorization: Bearer {REDACTED}" https://{REDACTED}/scim/Users
404 page not found

{"level":"debug","version":"2.8.3","build":"208031","application":"op-scim","request_id":"ck4770ns153kgsraliig","remote_addr":"10.11.74.120","status":404,"duration":0.008182,"size":19,"method":"GET","base_url":"{REDACTED}","path":"/scim/Users","time":"2023-09-18T15:57:54Z","message":"HTTP request"}

{"level":"debug","version":"2.8.3","build":"208031","application":"op-scim","request_id":"ck477bns153kgsralit0","remote_addr":"10.11.65.253","status":404,"duration":0.008577,"size":19,"method":"GET","base_url":"{REDACTED}","path":"/Users","time":"2023-09-18T15:58:38Z","message":"HTTP request"}

Hmm, one thing that is not documented here is that the usual SCIM endpoints are not enabled when connecting to Google Workspace. If that is the case, there may be another endpoint you can use for testing. It's relatively moot for that case, since the provisioning settings for Google Workspace requires signing in to the app in a web browser, which on its own should be enough to confirm its functionality.

These logs indicate that these requests are reaching your SCIM bridge, of course. The 404 means that these endpoints are not available.

[DaazKu]

As I said, I get a 404.

So you did, my bad. 🙃

curl --header "Authorization: Bearer {REDACTED}" https://{REDACTED}/scim/Users
404 page not found

{"level":"debug","version":"2.8.3","build":"208031","application":"op-scim","request_id":"ck4770ns153kgsraliig","remote_addr":"10.11.74.120","status":404,"duration":0.008182,"size":19,"method":"GET","base_url":"{REDACTED}","path":"/scim/Users","time":"2023-09-18T15:57:54Z","message":"HTTP request"}

{"level":"debug","version":"2.8.3","build":"208031","application":"op-scim","request_id":"ck477bns153kgsralit0","remote_addr":"10.11.65.253","status":404,"duration":0.008577,"size":19,"method":"GET","base_url":"{REDACTED}","path":"/Users","time":"2023-09-18T15:58:38Z","message":"HTTP request"}

Hmm, one thing that is not documented here is that the usual SCIM endpoints are not enabled when connecting to Google Workspace. If that is the case, there may be another endpoint you can use for testing. It's relatively moot for that case, since the provisioning settings for Google Workspace requires signing in to the app in a web browser, which on its own should be enough to confirm its functionality.

These logs indicate that these requests are reaching your SCIM bridge, of course. The 404 means that these endpoints are not available.

Updating the steps to something like:

• require login to the dashboard
• choose groups to sync
• trigger sync
• check in your 1password account if said users are synced

Would make sense as the testing step for google workspace then. Or something close to that and mention those endpoints are not available too.

[ag-adampike]

Good call. Thanks for your feedback!