update overview

docs/authentication/enterprise-connections/overview.mdx

@@ -3,43 +3,41 @@ title: Enterprise SSO
 description: Clerk provides Enterprise SSO to authenticate users via federated Identity Providers such such as Azure AD, Okta, Google Workspace and more.
 ---
 
-With Enterprise SSO, users can sign in seamlessly using their IdP's credentials and have their user data synchronized with Clerk. You can learn more about the process in the [Enterprise SSO authentication flows](/docs/authentication/enterprise-connections/authentication-flows) and [Account linking](/docs/authentication/enterprise-connections/account-linking) guides, or you can jump straight into integrating an IdP with Clerk.
+With Enterprise SSO, users can sign in seamlessly using their Identity Provider's (IdP) credentials and have their user data synchronized with Clerk. You can learn more about the process in the guides on [authentication flows](/docs/authentication/enterprise-connections/authentication-flows) and [account linking](/docs/authentication/enterprise-connections/account-linking).
 
-Clerk offers direct SAML integrations with [Microsoft Azure AD](/docs/authentication/enterprise-connections/saml/azure), [Google Workspace](/docs/authentication/enterprise-connections/saml/google), and [Okta Workforce](/docs/authentication/enterprise-connections/saml/okta) as IdPs. However, you can also [integrate with any other IdP](/docs/authentication/enterprise-connections/saml/custom-provider) that supports the SAML protocol.
+## SAML
 
-For [EASIE](https://easie.dev), Clerk offers integration with Google Workspace and Microsoft Entra ID. For _development instances_, Clerk uses preconfigured credentials and redirect URIs - no other configuration is needed. For production instances, you will need to generate your own Client ID and Client Secret, following the same steps outlined in our guides:
+Clerk supports Enterprise SSO via the SAML protocol, enabling you to create authentication strategies for an IdP. The following IdPs are supported: [Microsoft Azure AD](/docs/authentication/enterprise-connections/saml/azure), [Google Workspace](/docs/authentication/enterprise-connections/saml/google), and [Okta Workforce](/docs/authentication/enterprise-connections/saml/okta). However, you can also [integrate with any other IdP](/docs/authentication/enterprise-connections/saml/custom-provider) that supports the SAML protocol.
 
-- [Google](docs/authentication/social-connections/google)
-- [Microsoft](docs/authentication/social-connections/azure)
+### Allow subdomains
 
-## SAML vs. EASIE
+Authenticating via SAML SSO requires the user's email address domain to match the exact domain the SAML connection has been configured with. By default, subdomains are not supported. For example, a user with the email address `[email protected]` would not be able to use a SAML connection with the `example.com` domain in order to authenticate.
 
-[EASIE](https://easie.dev) allows for enterprise-grade SSO through a multi-tenant OpenID provider. It is designed to support an easier alternative to fully fledged SAML SSO, without requiring additional configuration in the Identity Provider and potential sharing of credentials or secrets.
+To configure subdomains for a SAML connection:
 
-A key consideration is [security](https://easie.dev#security). While Clerk implements measures to [address potential security issues](https://easie.dev/#mitigating-tenant-crossover-vulnerabilities), applications that require single-tenant Identity Providers should opt for SAML SSO.
+1. In the Clerk Dashboard, navigate to the [**SSO Connections**](https://dashboard.clerk.com/last-active?path=user-authentication/sso-connections) page.
+1. Select the SAML connection you want to allow subdomains for.
+1. Select the **Advanced** tab.
+1. Enable or disable the **Allow subdomains** option.
+1. Select **Save**.
 
-## Add your first Enterprise Connection
+> [!NOTE]
+> To enable the **Allow subdomains** option, your SAML connection domain must be an [eTLD+1](https://developer.mozilla.org/en-US/docs/Glossary/eTLD).
 
-1. Navigate to the [Clerk Dashboard](https://dashboard.clerk.com/last-active?path=user-authentication/sso-connections).
-1. In the top navigation, select **Configure**. Then in the sidebar, select **SSO Connections**.
-1. Click on **Add connection** on the top right and select **For specific domains**.
-1. Select one of the Identity Provider options based on your protocol of choice.
-1. On the next page, enter any required configuration information.
+## EASIE
 
-## Allow subdomains for SAML
+[EASIE](https://easie.dev) SSO is a way for applications to provide enterprise-grade SSO through a multi-tenant OpenID provider. It is designed to be an easier alternative to SAML SSO.
 
-Authenticating via SAML SSO requires the user's email address domain to match the exact domain the SAML connection has been configured with. By default, subdomains are not supported. For example, a user with the email address `[email protected]` would not be able to use a SAML connection with the `example.com` domain in order to authenticate.
+The following IdPs are supported: Google Workspace and Microsoft Entra ID. For _development instances_, Clerk uses preconfigured shared credentials and redirect URIs—no other configuration is needed. For _production instances_, you must provide custom credentials. Follow the steps outlined in the guides to complete the setup:
 
-To support SAML SSO with subdomains,
+- [Google](docs/authentication/social-connections/google)
+- [Microsoft](docs/authentication/social-connections/azure)
 
-1. Navigate to the [Clerk Dashboard](https://dashboard.clerk.com/last-active?path=user-authentication/sso-connections).
-1. In the top navigation, select **Configure**. Then in the sidebar, select **SSO Connections**.
-1. Select the SAML Connection you want to allow subdomains for.
-1. Select the **Advanced** tab.
-1. Toggle on the **Allow subdomains** option.
+## SAML vs. EASIE
 
-> [!NOTE]
-> To enable the **Allow subdomains** option, your SAML Connection domain must be an eTLD+1.
+The primary security difference between EASIE SSO and SAML SSO is that EASIE depends on a multi-tenant identity provider, while SAML depends on a single-tenant identity provider. Relying on a multi-tenant provider **increases** the risk that a user from one tenant will mistakenly be granted access to the resources of another tenant. While Clerk implements [measures to address this risk](https://easie.dev/#mitigating-tenant-crossover-vulnerabilities), apps that require single-tenant IdPs should opt for SAML.
+
+Read more in the [EASIE docs](https://easie.dev#security).
 
 ## Frequently asked questions (FAQ)
 

docs/manifest.json

@@ -528,6 +528,10 @@
                           "title": "SAML",
                           "items": [
                             [
+                              {
+                                "title": "Overview",
+                                "href": "/docs/authentication/enterprise-connections/saml/overview"
+                              },
                               {
                                 "title": "Azure",
                                 "href": "/docs/authentication/enterprise-connections/saml/azure"