依赖于多个不同应用程序的业务流程可能需要跨多个不同的安全域。 访问 Microsoft Windows 系统上的应用程序可能需要一组安全凭据，而访问 IBM 大型机上的应用程序可能需要不同的凭据，例如 RACF 用户名和密码。 对于用户而言，处理这类凭据是困难的，对自动化流程来说就更难了。 为了解决此问题，BizTalk Server 包括企业单一登录。
不要混淆 — 这不是一种机制，使用户对所有应用程序都有一个登录名。 相反，企业单一 Sign-On 提供了一种方法，将 Windows 用户 ID 映射到非 Windows 系统的用户凭据。 它无法解决组织的所有企业登录问题，但此服务可以简化在各种系统上使用应用程序的业务流程。
为非 Windows 系统创建关联应用程序
若要使用企业单一登录，管理员定义关联应用程序，每个应用程序表示非 Windows 系统或应用程序。 例如，关联应用程序可能是在 IBM 大型机上运行的 CICS 应用程序、Unix 上运行的 SAP ERP 系统或任何其他软件类型。 其中每个应用程序都有自己的身份验证机制，因此每个应用程序都需要自己的唯一凭据。
企业单一 Sign-On 在一个提供单点登录（SSO）功能的数据库中，存储用户的 Windows 用户 ID 与一个或多个关联应用程序的凭据之间的加密映射。 当此用户需要访问关联应用程序时，单个 Sign-On （SSO） 服务器可以在 SSO 数据库中查找该应用程序的凭据。 下图显示了工作原理。
在此示例中，某些应用程序发送到 BizTalk Server 的消息由业务流程处理，然后发送到 IBM 大型机上运行的关联应用程序。 企业单一 Sign-On 的工作是确保将正确的凭据（即正确的用户名和密码）与消息一起发送到关联应用程序。
使用 SSO 凭证处理消息
如图所示，当接收适配器收到消息时，适配器可以从 SSO 服务器 A（步骤 1）请求 SSO 票证。 此加密票证包含发出请求的用户的 Windows 标识和超时期限。 （不要将这与 Kerberos 票混淆 — 这不是一回事。获取票证后，它将作为属性添加到传入消息。 然后，该消息通过 BizTalk Server 引擎执行其正常路径，在此示例中，这意味着它由业务流程处理。 当此编排生成外发消息时，该消息还包含先前获取的 SSO 票证。
此新消息面向 IBM 大型机上运行的应用程序，因此它必须包含此用户访问该应用程序的适当凭据。 若要获取这些凭据，发送适配器会联系 SSO 服务器 B （步骤 2），提供它刚刚收到的消息（其中包含 SSO 票证），以及它尝试检索其凭据的关联应用程序的名称。 这种操作称为“兑换”，会促使 SSO 服务器 B 验证 SSO 票证，然后查找该应用程序中该用户的凭证（步骤 3）。 SSO 服务器 B 将这些凭据返回到发送适配器（步骤 4），该适配器使用它们向关联应用程序（步骤 5）发送经过适当身份验证的消息。
管理 SSO
企业单一 Sign-On 还包括管理工具，用于执行各种操作。 例如，对 SSO 数据库执行的所有操作都会被审核，因此提供了工具，允许管理员监视这些操作并设置各种审核级别。 其他工具允许管理员禁用特定关联应用程序、为用户打开和关闭单个映射，以及执行其他功能。 还有一个客户端实用工具，允许最终用户配置自己的凭据和映射。 与 BizTalk Server 的其他部分一样，企业单一 Sign-On 通过可编程 API 公开其服务。 第三方 BizTalk Server 适配器的创建者使用此 API 访问单一登录服务，管理员可以使用它来创建脚本来自动执行常见任务。
上述示例显示了企业单一登录的典型用法，但可以通过其他方式配置 SSO。 例如，较小的 BizTalk Server 安装可能只有一个 SSO 服务器，并且可以独立于 BizTalk Server 引擎使用企业单一 Sign-On。 （该技术还附带Microsoft Host Integration Server。