Why are SSO fields not saving when configuring SAML SSO?

Products

• CloudHealth

Issue/Introduction

Unable to save the 'Sign In Endpoint' and 'Signing Certificate' when configuring SAML SSO.

If configuring SSO via UI, a 409 error is displayed momentarily at the top of the page:

If configuring SSO via API, the following response will be returned:

{
"statusCode": 409,
"error": "Conflict",
"message": "A connection with the same name already exists",
"errorCode": "connection_conflict"
}

Cause

The cause is likely from another tenant (active or deleted) is using this domain already.

Resolution

The solution is to locate the tenant that has this domain already claimed. There are a few ways to do this:

• Search for the impacted domain within https://apps.cloudhealthtech.com/admin/users. From here you can pull in the "customer" field to reveal users who share the same email domain within different tenants. It's possible one of the other tenants has the domain claimed.
• Search the impacted domain within Zendesk to see if it has been mentioned previously. This may lead you to the tenant where it's claimed. 
• Partner's tend to hit this problem often as they set up test tenants with SSO and then soft delete those tenant's before fully onboarding the customer. The problem is that deleting the tenant does not wipe out the SSO connection.. so when they go to claim the domain in the new tenant production account they hit the 409 error. In this scenario, a good place to start is by searching for a tenant with a similar name in the "Restore Customers" Proactive Support tool.

https://labs.cloudhealthtech.com/admin/proactive_support/restore_customer 

If a possible match is found:

1. Restore the tenant and switch into it.
2. Go to SSO page and verify if the same domain is configured and then unconfigure SSO. 
3. Next, go Partner Customer List, locate the restored tenant and delete them again.

If unable to locate the tenant, than reach out to team-vertex:

Vertex will need to either tell us where the domain is claimed so that we can wipe it, or they will need to manually wipe it if tied to a hard deleted tenant or they can remove the auth0 connection name.