Users in Okta to 1password groups not syncing

Hi @varun118. It's good to hear you were able to upgrade the SCIM bridge to v2.2.1. In order to look into this issue further, we need some more details about your account and a complete log. Can I please ask you to contact us at our support email so you can provide these to us? You can find the contact form here, https://support.1password.com/contact. Please let me know once you have done that and we can expedite the support process from our end. Thank you!

Hi @DeVille_1P we have finally upgraded it to 2.2.1 by adding empty --letsencrypt-domain and --port values respectively.
Scim-bridge is up and running and on latest version.
Health also looks good.

But we were unable to solve the main issue "Okta groups not syncing with 1password user groups"
We tried to make changes to the group by adding new users and pushed
in the UI it says "Automated User Provisioning updated the group okta-1password-cs 9:52 pm"
but no changes are reflecting in the 1password user group

Group id "i7xsp2dz3y4utwllvufz7hx5kq"

and these are the logs

{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophdg","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"group found"}
{"level":"debug","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophdg","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"ref URL is required to populate members ref for group"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophdg","remote_addr":"10.147.141.250","status":200,"duration":404.712527,"size":421,"method":"GET","path":"/Groups/i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"HTTP request"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophe0","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"applying field operations to group"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophe0","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"applying other group field operations"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophe0","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"group name changed"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tgigua0o53aqophe0","remote_addr":"10.147.141.250","status":200,"duration":297.343131,"size":292,"method":"PATCH","path":"/Groups/i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:11:54Z","message":"HTTP request"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi3g","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"group found"}
{"level":"debug","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi3g","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"ref URL is required to populate members ref for group"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi3g","remote_addr":"10.147.157.217","status":200,"duration":275.313547,"size":421,"method":"GET","path":"/Groups/i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"HTTP request"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi40","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"applying field operations to group"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi40","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"applying other group field operations"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi40","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"group name changed"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tio8ua0o53aqopi40","remote_addr":"10.147.157.217","status":200,"duration":290.503945,"size":292,"method":"PATCH","path":"/Groups/i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:33Z","message":"HTTP request"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tiogua0o53aqopi4g","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:34Z","message":"all operations skipped"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tiogua0o53aqopi4g","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:34Z","message":"applying field operations to group"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tiogua0o53aqopi4g","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","group":"i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:34Z","message":"applying other group field operations"}
{"level":"info","version":"2.2.1","build":"202011","application":"op-scim","component":"SCIMServer","request_id":"c69tiogua0o53aqopi4g","remote_addr":"10.147.157.217","status":200,"duration":233.983915,"size":292,"method":"PATCH","path":"/Groups/i7xsp2dz3y4utwllvufz7hx5kq","time":"2021-11-16T16:16:34Z","message":"HTTP request"}

Need some help on this
let me know if you need any further details

Hi @fdietrich. I'm happy that you managed to solve the issue and thank you for sharing your solution.

Hi @varun118.

Thank you for confirming the open ports.

Based on your earlier message it sounds like you are running the SCIM bridge behind a load balancer (ELB) that is already doing TLS termination (using an AWS certificate). If this is the case then you will not need the SCIM bridge to obtain its own certificate.

You can override the default behaviour of the SCIM bridge by setting the following environment variables for the SCIM bridge:
* OP_LETSENCRYPT_DOMAIN to an empty string (""). This will prevent the SCIM bridge from trying to obtain a certificate from Let's Encrypt.
* OP_PORT to the port you have configured the load balancer to use to forward traffic to the SCIM bridge, such as 80 or 8080 for example. This changes the listening port of the SCIM bridge when not using LetsEncrypt TLS, and it defaults to 3002.

Note that both of these variables can also be passed to the SCIM bridge as command line arguments, --letsencrypt-domain and --port respectively.

Hi @DeVille_1P the ports were opened. In our case the problem was with the DNS. We we're using as fqdn and DNS record the kubernetes API generated from Azure, but it required an additional custom domain to be registered.

Hi @DeVille_1P both port 80 and 443 were open
but still having this issue.

Hi @fdietrich.

Thanks for sharing the error log.

Could you also check your configuration to ensure that port 443 is open?

Hi @varun118.

Thank you for providing the additional information. You mentioned that you have port 80 open but I wanted to ask if you have port 443 open?

With the release of version 2.2.0 (and later) we have moved to a TLS-ALPN-01 challenge for Let's Encrypt. This means that a direct connection using port 443 is possible, which is one of the main advantages. This means that port 80 is no longer required for obtaining a certificate from Let's Encrypt.

Hi

Do you have any update on this

Thanks

we have spunned up a docker container with scimbridge on ec2 instance which has a ELB with aws certs on it
but there are no specific redirection rules present on it