Health monitoring is wonky in the new SCIM integration
First things first - I love to see the new SCIM integration and the ability to enforce 2FA via policy. 1Password is a lovely product.
Did, however, run into a faulty error message for the integration.
Given the nature of the integration, it makes good sense to filter inbound traffic before it reaches the SCIM bridge itself. We limit ours to only the IP ranges presented by our IDP.
The health monitoring for the SCIM integration is using a third party service - Checkly - to connect to the SCIM bridge. Per their information page, they don't maintain a list of addresses they might be connecting from; we cannot make a similar whitelist for their ranges without allowing all of AWS, which would sort of defeat the purpose. Thus, cannot use.
Additionally, if health monitoring is enabled, the error message in the 1Password integrations page is "There’s a problem with the SCIM bridge. Check its configuration and make sure it can connect to 1Password and your identity provider.", which is precise, helpful and incorrect ;-)
Figured I'd leave a note for the next person running into the same error; it could well be a red herring.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @andsten,
Graham here from the 1Password Provisioning Development team.
Thanks for taking the time to write such thoughtful and detailed feedback! We are listening and take your feedback to heart.
You are correct that neither Checkly nor 1Password publish IP ranges for our servers. In our case, that is because we don't have static hosts and instead any filtering should be done on our domains (as documented here: https://support.1password.com/ports-domains/). Without knowing more about their internal infrastructure, I can only guess Checkly must have similar reasons. I acknowledge that makes your job a bit more difficult with regards to locking down the 1Password SCIM Bridge deployed in your environment. That is partly why we take such great care around securing the generation, storage, and use of your
scimsessionfile and associated bearer token.With regards to the error message, you are correct that not allowing Checkly to reach your SCIM Bridge will give the
There's a problem with your SCIM bridgemessage. From the monitoring service's perspective, it cannot differentiate between a failed SCIM bridge and protected SCIM bridge. However I think we can make this a bit better. Specifically, we will:
- Examine what other information we can use to better inform the monitoring error messages.
- Chat with Checkly regarding static IP ranges.Of course, we can't promise anything on either point at this time.
Thanks for the feedback! Keep it coming!
Graham
0 -
It seems tho that the Health Monitoring section of the new integration is hitting /monitor and returning a 404 which is why health always shows as broken, even though the SCIM bridge still works fine. I'd expect it to use /ping instead, which does return a 200 and is what we use in our ALB to monitor things. Note this is with 1.6.2 and /monitor still 404's
0 -
Hi @dlgordon,
You are correct, we are hitting the
/monitoringroute rather than the/pingroute. That is because that route provides more granular health information compared to/ping, which in turn allows us to give you more nuanced alerts and monitoring information. The same information can be found by either hitting the/healthroute or navigating to the status page in your web browser.Additionally you are correct the
/monitoringroute does not use the same bearer token as other routes, hence the 404. That is because there is a unique bearer token for that route. Your SCIM Bridge's health information should be protected, hence it is an authenticated endpoint. However we also don't want to ask you to give Checkly your bearer token, as that would give them the ability to take provisioning actions and see private information. Therefore there is a unique bearer token and verifier generated just for Checkly that constrains their access to just that route. They should see health information, and nothing more. You can see evidence of that by examining your scimsession file, and noting thehealthVerifierfield against which their bearer token is verified.Let me know what further questions you have.
Graham
0 -
Hi
I don't fully understand. We don't use Checkly. Are you saying 1Password use Checkly for the monitoring status on that page?
Either way, the status check in the integrations page doesn't work - or at least not in my case because whatever is hitting /monitoring is unauthenticated and it's not clear how or who to provide a health specific bearer token to.
0 -
Hi @dlgordon,
1Password leverages Checkly as a monitoring provider. When you turn on provisioning for a recent version of the 1Password SCIM bridge, you have the option to enable monitoring. If you choose to enable monitoring, we leverage Checkly to keep an eye on your 1Password SCIM bridge. Should the state of your bridge change unexpectedly, 1Password will alert you via email.
There is no additional cost to you, and the feature can be completely disabled. This is a new feature that we are slowly rolling out. More information, details, and documentation are coming very soon.
As to your specific circumstance, there could be an issue with how it was initially set up, or perhaps you got caught in one of a few buggy edge cases we have since fixed. Either way, I would strongly encourage you to reach out to
support+scim@1password.comand we can help you get monitoring up and running without exposing private personal information on this public forum.Let me know what further questions you have.
Graham
0 -
Gotcha, I understand, thanks.
0 -
Thanks all - after reading these comments, I destroyed and re-stood up my my SCIM instance, with rotated credentials, and everything has come back to life, including /monitoring working fine, so thanks all.
0
