Hey everyone! 👋 I’ve been knee-deep in evaluating Claw (the dev-first observability platform) for our SaaS engineering team, and I’ve hit a crucial question that I’m hoping some of you have already navigated.
**Our context:**
- Team size: ~45 engineers, split into 6 product squads.
- Stack: Primarily Kubernetes (EKS), with workloads in Go and Python. We use Terraform for infra, and our current observability is a messy mix of open-source tools (Prometheus, Grafana, Jaeger) that’s becoming a maintenance headache.
- We are **not** considering self-hosted for this solution—we want a fully managed service to reduce toil.
- Our auth is **non-negotiable**: We use Okta as our SAML 2.0 IdP for all internal tools. Every engineer must be able to log in with their existing Okta credentials, and access should be role-mapped via groups.
I’ve read through Claw’s documentation on SSO, and it *says* it supports SAML, but the details are pretty high-level. My experience is that the devil is in the details with these integrations. I’m documenting my evaluation process for the team, and I’d love to hear from anyone who has actually implemented this.
**My specific questions:**
* **Group Synchronization:** Can Claw consume group memberships from the SAML assertion? We need to mirror our Okta groups (e.g., `platform-engineers`, `backend-squad-alpha`) to Claw teams for permissions. Do you map them via a claim like ` http://schemas.xmlsoap.org/claims/Group`, or is it a custom attribute?
* **Just-in-Time (JIT) Provisioning:** Does Claw create user accounts on first SAML login automatically? Or does an admin need to pre-provision users?
* **Attribute Mapping:** Any gotchas with the required NameID format or other attributes? A snippet of a working Terraform config or the Okta SAML app setup would be **incredibly** helpful. Something like:
```hcl
# Hypothetical Claw provider Terraform snippet - is this close?
resource "okta_app_saml" "claw" {
label = "Claw Observability"
sso_url = "https://ourcompany.claw.dev/sso/saml"
recipient = "https://ourcompany.claw.dev/sso/saml/acs"
audience = "https://ourcompany.claw.dev"
name_id_format = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
subject_name_id_template = "user.email"
attribute_statements {
name = "groups"
type = "GROUP"
namespace = "urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"
values = ["Everyone", "Engineering", "Okta-Group-Platform"]
}
}
```
* **Admin Experience:** Once SAML is enforced, can local logins be disabled entirely? How is the initial "break-glass" admin configured?
I’m particularly wary of setting up something that becomes a support burden for user onboarding/offboarding. If you’ve gone through this integration—especially with Okta—I’d be so grateful for any notes, config snippets, or warnings about pitfalls. Happy to share my complete evaluation doc once it’s done!