Salesforce Experience Cloud 架构深度解析：外部身份、许可证与安全最佳实践

背景与应用场景

作为一名 Salesforce 架构师 (Salesforce Architect)，我在设计企业级解决方案时，Experience Cloud（前身为 Community Cloud）始终是连接企业与其客户、合作伙伴和员工生态系统的核心组件。它不仅仅是一个简单的门户网站或论坛，而是一个功能强大的平台，用于构建高度定制化、品牌化和移动响应式的数字体验空间。企业可以利用它来创建客户服务中心、合作伙伴关系管理 (PRM) 门户、B2B 电商网站，甚至是特定于某个项目的协作空间。

然而，构建一个成功的 Experience Cloud 站点，挑战远不止于页面布局和组件配置。真正的复杂性在于其底层架构的设计。当外部用户数量从几百人激增至数十万甚至数百万时，架构师必须面对一系列严峻的挑战：

身份管理 (Identity Management): 如何安全、无缝地管理海量外部用户的身份验证和授权？如何与企业现有的身份提供商 (IdP) 集成，实现单点登录 (SSO)？

许可证成本与功能平衡 (Licensing Model):

数据安全与可见性 (Data Security & Visibility): 外部用户本质上是“不受信任的”，我们如何确保他们只能访问其权限范围内的数据，严防数据泄露？如何为大量没有角色的用户设计一个可扩展的记录共享模型？
可扩展性与性能 (Scalability & Performance): 随着用户量和数据量的增长，如何确保站点的性能不会下降，始终提供流畅的用户体验？

本文将从 Salesforce 架构师的视角，深入探讨构建安全、可扩展的 Experience Cloud 解决方案的三大核心支柱：身份、许可证和安全模型，并结合最佳实践，为复杂的业务场景提供架构设计思路。

原理说明

一个健壮的 Experience Cloud 架构设计，始于对以下三个核心概念的深刻理解和权衡。

1. 外部身份管理 (External Identity Management)

外部身份是 Experience Cloud 的基石。与拥有完整 Salesforce 许可证、在组织内部拥有角色的内部用户不同，外部用户（客户、合作伙伴）的身份管理需要专门的解决方案。

Salesforce External Identity 是一种专门为此设计的许可证，它以极低的成本提供了强大的身份验证功能。它允许用户通过社交登录（如 Google, Facebook）、单点登录 (SSO) 或 Salesforce 本地用户名/密码进行登录。从架构上看，身份管理策略通常分为以下几种：

本地身份验证: 用户在 Experience Cloud 上直接注册和登录。这适用于没有现有身份系统的场景。我们可以通过自定义注册流程和登录流程 (Login Flows) 来增强安全性，例如在登录时强制用户同意新的服务条款或完成多重身份验证 (MFA)。
联合身份验证 (Federated Authentication) - SSO: 这是企业级应用的首选。通过使用 SAML (Security Assertion Markup Language) 或 OpenID Connect 协议，用户可以使用其现有的企业凭据（如 Active Directory 或 Okta）登录 Experience Cloud。这不仅提升了用户体验，也简化了 IT 部门的密码管理工作。作为架构师，我们需要设计 IdP 发起或 SP (Service Provider) 发起的登录流程，并确保断言 (assertion) 中包含了正确的用户属性映射。
委托身份验证 (Delegated Authentication): 在某些特殊场景下，Salesforce 可以将密码验证的请求委托给外部的 Web Service。这种方式现在已不常用，SSO 是更现代和安全的选择。

Login Flows 是一个强大的工具，允许我们在用户成功通过身份验证之后、进入站点之前，插入一个自定义的业务流程。例如，我们可以检查用户是否来自受限制的 IP 地址、提示他们更新个人资料，或者根据其属性将其重定向到不同的页面。这为身份验证过程增加了极大的灵活性和控制力。

2. 许可证模型选择 (License Model Selection)

许可证的选择直接决定了 Experience Cloud 的功能边界、安全模型和最终成本，是架构设计中最关键的决策之一。错误的选择可能会导致项目后期功能无法实现或预算严重超支。

以下是主流的 Experience Cloud 许可证类型及其架构考量：

Customer Community: 这是为大量 B2C 客户设计的许可证，成本最低。其用户没有 Salesforce 角色 (Role)，记录的访问权限主要通过共享集 (Sharing Sets) 和共享组 (Share Groups) 来控制。它适用于自助服务、知识库访问和案例管理等场景。架构师必须意识到，由于缺乏角色层级，复杂的、基于上下级关系的共享规则无法在此模型下实现。
Customer Community Plus: 这是 Customer Community 的增强版。用户同样没有角色，但可以访问报表和仪表盘，并拥有对某些标准对象（如 Account, Contact, Case）的高级共享权限。它适用于需要更复杂数据共享的 B2C 或 B2B 场景，例如，允许客户查看其所在公司的所有案例。
Partner Community: 这是功能最强大的许可证，专为合作伙伴（如经销商、代理商）设计。用户拥有 Salesforce 角色，可以利用基于角色的共享规则 (Role-Based Sharing) 来访问数据，例如，渠道经理可以查看其下属所有渠道销售人员的业务机会。它支持 Leads, Opportunities 和 Campaigns 等销售对象。选择此许可证意味着我们可以构建一个功能完备的 PRM 门户。
External Apps: 这种许可证提供了 Partner Community 的大部分功能，但更侧重于与 Salesforce Platform 的深度集成和自定义对象的应用，通常用于构建高度定制化的商业应用程序。

作为架构师，我们的职责是与业务方深入沟通，理解其对数据可见性、协作模式和报表分析的真实需求，然后将这些需求映射到最合适的许可证类型上，并向利益相关者清晰地阐述不同选择所带来的功能限制和成本影响。

3. 安全与共享模型 (Security & Sharing Model)

Experience Cloud 的安全模型是一个多层次的结构，我们需要在每一层都进行精心的设计。

对象级安全 (Object-Level Security): 通过简档 (Profile) 和权限集 (Permission Set) 来控制用户对特定对象的创建、读取、更新、删除 (CRUD) 权限。最佳实践是使用权限集来授予权限，而不是直接修改简档，这使得权限管理更加灵活和模块化。对于外部用户，必须遵循最小权限原则 (Principle of Least Privilege)。
字段级安全 (Field-Level Security): 在简档或权限集中，我们可以精确控制用户对特定字段的可见性和可编辑性。
记录级共享 (Record-Level Sharing): 这是外部用户安全模型中最复杂、也最重要的部分。
- 对于拥有角色的 Partner Community 用户，我们可以使用标准的 Salesforce 共享机制：组织范围默认设置 (OWD)、角色层级、共享规则 (Sharing Rules) 和手动共享 (Manual Sharing)。
- 对于没有角色的 Customer Community 和 Community Plus 用户，传统的共享模型不再适用。我们必须依赖于 Sharing Sets。Sharing Set 基于用户和目标记录之间的共同字段（通常是用户的 Contact.AccountId 与目标记录的查找字段）来授予访问权限。例如，一个 Sharing Set 可以配置为：“允许用户访问所有与该用户所在客户 (Account) 相关联的案例 (Case)”。对于更复杂的场景，可以使用 Apex Managed Sharing，通过代码来创建 `Share` 对象记录，实现动态的、基于业务逻辑的共享。
其他安全设置: 还需要考虑站点的整体安全设置，如点击劫持保护 (Clickjack Protection)、内容安全策略 (Content Security Policy - CSP) 以及对访客用户 (Guest User) 权限的严格限制。Salesforce 近年来持续收紧访客用户的安全策略，架构师必须确保访客用户无法访问任何非公开数据。

示例代码

在设计身份验证流程时，一个常见的需求是自定义用户注册逻辑。例如，当一个新用户通过 SSO 或社交登录首次访问时，我们可能需要在 Salesforce 中为他创建一个用户记录，并将其关联到正确的客户 (Account) 或联系人 (Contact)。这可以通过实现 `Auth.RegistrationHandler` 接口来完成。这是一个典型的架构扩展点，将身份验证与 Salesforce 内部的数据模型和业务流程连接起来。

以下示例代码来自 Salesforce 官方文档，展示了一个简单的注册处理程序。当一个新用户通过身份验证服务登录时，此代码会检查 Salesforce 中是否存在该用户。如果不存在，它会创建一个新的用户和联系人，并将它们关联起来。

// Registration handler for external authentication providers.
// It creates a user, contact, and account.
global class MyRegHandler implements Auth.RegistrationHandler {

    // Creates a new user or returns an existing user.
    // The user is created for the given portal, or for the site if the portal is null.
    // The user is created with the data provided by the authentication provider.
    // The method can also be used to update an existing user.
    global User createUser(Id portalId, Auth.UserData data) {
        // --- 1. 架构考量：事务边界与数据一致性 ---
        // 整个 createUser 方法在一个单一事务中执行。
        // 如果在创建 Account, Contact 或 User 的任何一步失败，整个事务将回滚，
        // 避免产生孤立数据。
        
        // --- 2. 架构考量：避免硬编码，使用自定义设置/元数据 ---
        // 在生产环境中，Profile ID 和 Account Name 不应硬编码。
        // 应使用 Custom Metadata Types 或 Custom Settings 来存储这些配置，
        // 以便于在不同环境中进行部署和修改，而无需更改代码。
        String profileId = [SELECT Id FROM Profile WHERE Name = 'Your Experience Cloud Profile Name'].Id;
        String acctName = 'Default Self-Reg Account';

        // --- 3. 架构考量：用户唯一性检查 ---
        // 检查用户是否已存在是至关重要的，以防止重复创建。
        // 使用 email 或 federated identifier 是常见的唯一性标识。
        User u = [SELECT Id FROM User WHERE Username = :data.username];
        if (u != null) {
            // 如果用户已存在，可以直接返回，或在此处添加更新逻辑
            return u;
        }

        // --- 4. 架构考量：数据模型的关联与所有权 ---
        // 创建一个客户 (Account) 来容纳所有自注册用户，或根据业务逻辑查找现有客户。
        // 注意：将大量用户关联到单个客户可能导致数据倾斜 (Data Skew)，
        // 影响性能。对于大规模 B2C 场景，应设计合理的客户划分策略。
        Account acct = [SELECT Id, Name FROM Account WHERE Name = :acctName];
        if (acct == null) {
            acct = new Account(Name = acctName);
            insert acct;
        }

        // --- 5. 架构考量：数据填充与默认值 ---
        // 从 Auth.UserData 对象中获取身份提供商传递过来的信息，
        // 如 firstName, lastName, email 等，填充到 Contact 和 User 对象中。
        Contact c = new Contact();
        c.FirstName = data.firstName;
        c.LastName = data.lastName;
        c.Email = data.email;
        c.AccountId = acct.Id;
        insert c;

        // --- 6. 架构考量：用户创建与许可证分配 ---
        // 创建 User 对象。用户的 ProfileId 决定了他所使用的许可证类型
        // (例如，与 Partner Community 许可证关联的简档)。
        // 别名 (Alias) 必须是唯一的。
        User newUser = new User();
        newUser.Username = data.username;
        newUser.Email = data.email;
        newUser.LastName = data.lastName;
        newUser.FirstName = data.firstName;
        String alias = data.username;
        if (alias.length() > 8) {
            alias = alias.substring(0, 8);
        }
        newUser.Alias = alias;
        newUser.ProfileId = profileId;
        newUser.ContactId = c.Id;
        newUser.LanguageLocaleKey = UserInfo.getLocale();
        newUser.LocaleSidKey = UserInfo.getLocale();
        newUser.TimeZoneSidKey = 'America/Los_Angeles'; // 应考虑动态设置
        newUser.EmailEncodingKey = 'UTF-8';

        return newUser;
    }

    // Updates an existing user with data from the authentication provider.
    // The user is looked up using the user ID.
    // The method is called when a user logs in with an existing account.
    global void updateUser(Id userId, Id portalId, Auth.UserData data) {
        User u = new User(Id = userId);
        // --- 7. 架构考量：用户信息同步 ---
        // 在此方法中，可以实现从身份提供商到 Salesforce 的用户信息同步逻辑。
        // 例如，如果用户的姓氏在外部系统中发生了变化，
        // 每次登录时都会更新到 Salesforce 中对应的 User 和 Contact 记录。
        u.Email = data.email;
        u.LastName = data.lastName;
        u.FirstName = data.firstName;
        update u;
    }
}

注意事项

权限与简档 (Permissions & Profiles): 为外部用户创建的简档必须是克隆自标准的外部用户简档（如 `Customer Community User`），并且必须遵循最小权限原则。永远不要给外部用户分配 `System Administrator` 或任何具有 `Modify All Data` 权限的简档。
API 限制 (API Limits): 大量外部用户通过 API 或与 LWC/Aura 组件交互会消耗组织的 API 调用总数。在架构设计阶段，必须评估预期的用户活动，并考虑使用缓存策略或将某些操作移至异步处理，以避免触及 Salesforce 的 Governor Limits。
数据倾斜 (Data Skew): 如前文所述，当大量外部用户（或其相关记录，如 Case）都关联到同一个客户 (Account) 记录时，会发生所有权倾斜 (Ownership Skew)。这会导致在执行共享计算、报表和查询时性能急剧下降。架构上应设计分布式的客户模型，避免单点瓶颈。
混合 DML 错误 (Mixed DML Errors): 在 `RegistrationHandler` 或其他自动化流程中，如果尝试在同一个事务中同时操作设置对象（如 `User`）和非设置对象（如 `Account`），可能会触发 `Mixed DML Operation` 错误。虽然在注册处理器的上下文中 Salesforce 通常会处理好这个问题，但在其他自定义 Apex 代码中需要特别注意，可能需要使用未来方法 (`@future`) 或队列化 Apex (`Queueable Apex`) 来分离事务。
访客用户安全 (Guest User Security): Salesforce 对访客用户（即未登录用户）的权限限制越来越严格。确保 OWD 中外部访问权限设置为 `Private`，并取消勾选所有访客用户简档中不必要的对象和字段权限。使用专门的 Guest User Sharing Rule 来有限地开放记录访问权限。

总结与最佳实践

作为 Salesforce 架构师，设计 Experience Cloud 解决方案是一项涉及多方面权衡的系统工程。一个成功的架构不仅能满足当前的业务需求，更能为未来的扩展和变化提供坚实的基础。

以下是架构设计的最佳实践清单：

身份先行 (Identity First): 在项目启动阶段就确定身份管理策略。是使用 Salesforce 本地身份，还是与企业 IdP 进行 SSO 集成？这将影响整个项目的技术选型和实施路径。
精准的许可证规划 (Precise Licensing): 深入分析业务需求，特别是对报表、仪表盘和基于角色层级的数据共享需求，选择最具成本效益的许可证组合。向客户清晰说明不同许可证的功能边界。
设计可扩展的共享模型 (Scalable Sharing Model): 对于大量用户的场景，优先考虑使用 Sharing Sets。避免为成千上万的 Customer Community 用户创建不必要的角色，因为这会严重影响组织性能。如果 Sharing Sets 无法满足复杂的业务需求，再考虑使用 Apex Managed Sharing 作为补充。
拥抱权限集 (Embrace Permission Sets): 将核心权限封装在权限集中，而不是直接修改简档。这使得权限管理更加清晰、可维护，并易于在不同用户群体之间复用。
为性能而设计 (Design for Performance): 从第一天起就考虑大规模数据和高并发用户带来的性能挑战。注意避免数据倾斜，优化 SOQL 查询，并合理利用平台缓存。
安全审计与持续审查 (Security Audit & Continuous Review): 定期审查外部用户的简档、权限集和共享规则，确保它们仍然遵循最小权限原则。关注 Salesforce 安全更新，及时调整配置，特别是针对访客用户的安全策略。

通过系统性地规划身份、许可证和安全模型这三大支柱，我们可以构建出既能满足复杂业务需求，又安全、可靠且易于维护的 Salesforce Experience Cloud 解决方案，从而真正释放其作为企业数字体验核心平台的巨大价值。

Salesforce中文网