使用 SAML 2.0 标识提供者 (IdP) 进行单一登录

项目
07/16/2024

本文档介绍有关将基于符合 SAML 2.0 的 SP-Lite 配置文件的标识提供者作为首选安全令牌服务 (STS)/标识提供者的信息。如果已经在本地拥有可以使用 SAML 2.0 访问的用户目录和密码存储，此方案将非常有用。可使用这个现有的用户目录登录到 Microsoft 365 和其他受 Microsoft Entra ID 保护的资源。 SAML 2.0 SP-Lite 配置文件基于基于广泛使用的安全断言标记语言 (SAML) 联合标识标准，可提供登录和属性交换框架。

注意

有关经过测试的用于 Microsoft Entra ID 的第三方 Idp 列表，请参阅 Microsoft Entra 联合兼容性列表

Microsoft 支持此登录体验，允许将 Azure 云服务（例如 Microsoft 365）与正确配置的基于 SAML 2.0 配置文件的 IdP 集成。 SAML 2.0 标识提供者是第三方产品，因此，Microsoft 不会对与其相关的部署、配置、故障排除最佳做法等提供支持。正确配置后，可以使用 Microsoft Connectivity Analyzer 工具来测试是否已正确配置了与 SAML 2.0 标识提供者的集成，下文将详细介绍。有关基于 SAML 2.0 SP-Lite 配置文件的标识提供者的详细信息，请咨询其提供组织。

重要

在使用 SAML 2.0 标识提供者的这个登录方案中，仅可使用有限的一组客户端，其中包括：

基于 Web 的客户端，例如 Outlook Web Access 和 SharePoint Online
使用基本身份验证和受支持的 Exchange 访问方法（例如 IMAP、POP、Active Sync、MAPI 等）的电子邮件处理量大的客户端。（需要部署增强型客户端协议终结点），包括：
- Microsoft Outlook 2010/Outlook 2013/Outlook 2016、Apple iPhone（各种 iOS 版本）
- 各种 Google Android 设备
- Windows Phone 7、Windows Phone 7.8 和 Windows Phone 8.0
- Windows 8 邮件客户端和 Windows 8.1 邮件客户端
- Windows 10 邮件客户端

其他所有客户端都不可在这种采用 SAML 2.0 标识提供者的登录方案中使用。例如，Lync 2010 桌面客户端无法登录到配置了 SAML 2.0 标识提供者的单一登录服务中。

Microsoft Entra SAML 2.0 协议要求

本文档详细介绍了 SAML 2.0 标识提供者联合 Microsoft Entra ID 进行身份验证，以启用登录到一个或多个 Microsoft 云服务（例如 Microsoft 365）的功能时，必须实现的协议和消息格式的相关要求。此方案中使用的 Azure 云服务的 SAML 2.0 信赖方 (SP-STS) 为 Microsoft Entra ID。

建议确保 SAML 2.0 标识提供者输出的消息尽量与提供的示例跟踪类似。此外，尽可能使用提供的 Microsoft Entra 元数据的特定属性值。如果觉得对输出的消息满意，可以根据如下所述使用 Microsoft Connectivity Analyzer 进行测试。

可以从此 URL 下载 Microsoft Entra 元数据：https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml。对于使用中国特定的 Microsoft 365 实例的中国客户而言，应使用以下联合终结点：https://nexus.partner.microsoftonline-p.cn/federationmetadata/saml20/federationmetadata.xml。

SAML 协议要求

本部署详述如何将请求和响应消息对放置在一起，以便正确设置消息格式。

可以配置将 Microsoft Entra ID 与使用 SAML 2.0 SP Lite 配置文件的标识提供者配合使用，具体需求如下所示。结合自动和手动测试使用示例 SAML 请求和响应消息，可以实现与 Microsoft Entra ID 的互操作性。

签名块要求

在 SAML 响应消息中，签名节点包含有关消息本身的数字签名的信息。签名块具有以下要求：

断言节点本身必须签名
必须使用 RSA-sha1 算法作为 DigestMethod。不接受其他数字签名算法。 <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>
还可以为 XML 文档签名。
转换算法必须与以下示例中的值匹配：<ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#"/>
SignatureMethod 算法必须与以下示例匹配：<ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

注意

为了提高安全性，SHA-1 算法已被弃用。请确保使用更安全的算法，例如 SHA-256。可以在此处了解详细信息。

支持的绑定

绑定是所需的传输相关通信参数。以下要求适用于绑定：

HTTPS 是所需的传输。
登录期间，Microsoft Entra ID 需要 HTTP POST 进行令牌提交。
Microsoft Entra ID 会使用 HTTP POST 来处理发送给标识提供者的身份验证请求，并使用 REDIRECT 来处理发送给标识提供者的注销消息。

必需属性

下表显示了针对 SAML 2.0 消息中的特定属性的要求。

Attribute	说明
NameID	此断言的值必须与 Microsoft Entra 用户的 ImmutableID 一样。它最多可以有 64 个字母数字字符。任何非 html 安全型字符都必须进行编码，例如，“+”字符显示为“.2B”。
IDPEmail	用户主体名称 (UPN) 将在 SAML 响应中以 IDPEmail 元素的形式列出，这是用户在 Microsoft Entra ID/Microsoft 365 中的 UserPrincipalName (UPN)。 UPN 采用电子邮件地址格式。 Windows Microsoft 365 中的 UPN 值 (Microsoft Entra ID)。
颁发者	必须是标识提供者的 URI。不得重复使用示例消息中的颁发者。如果 Microsoft Entra 租户中存在多个顶级域，颁发者必须与每个域配置的指定 URI 设置相匹配。

重要

针对 SAML 2.0，Microsoft Entra ID 当前支持以下 NameID 格式的 URI：urn:oasis:names:tc:SAML:2.0:nameid-format:persistent。

SAML 请求与响应消息示例

显示的请求与响应消息对是针对登录消息交换的。以下是从 Microsoft Entra ID 发送到示例 SAML 2.0 标识提供者的示例请求消息。示例 SAML 2.0 标识提供者为 Active Directory 联合身份验证服务 (AD FS)，已配置为使用 SAML-P 协议。此外，还针对其他 SAML 2.0 标识提供者完成了互操作性测试。

<samlp:AuthnRequest ID="_1e089e5c-a976-4881-af74-3b92c89e7e2c" Version="2.0" IssueInstant="2024-03-12T14:00:18.450Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:partner.microsoftonline.cn</Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

如果按照 internaldomainfederation-update 中的说明启用 isSignedAuthenticationRequestRequired，则请求将如下例所示：

  <samlp:AuthnRequest ID="_1868c6f2-1fdd-40b9-818f-b4b44efb92c5" Version="2.0" IssueInstant="2024-03-11T16:51:17.120Z" Destination="https://fs.contoso.com/adfs/ls/" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:partner.microsoftonline.cn</Issuer><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#_1868c6f2-1fdd-40b9-818f-b4b44efb92c5"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><DigestValue>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</DigestValue></Reference></SignedInfo><SignatureValue>cD2eF3gH4iJ5k...L6mN7-oP8qR9sT==</SignatureValue><KeyInfo><ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509SKI>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509SKI></ds:X509Data><ds:KeyName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">MicrosoftOnline</ds:KeyName></KeyInfo></Signature><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/></samlp:AuthnRequest>

下面是一个示例响应消息，它从符合 SAML 2.0 的标识提供者示例发送到 Microsoft Entra ID/Microsoft 365。

    <samlp:Response ID="_592c022f-e85e-4d23-b55b-9141c95cd2a5" Version="2.0" IssueInstant="2014-01-31T15:36:31.357Z" Destination="https://login.partner.microsoftonline.cn/login.srf" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </samlp:Status>
    <Assertion ID="_7e3c1bcd-f180-4f78-83e1-7680920793aa" IssueInstant="2014-01-31T15:36:31.279Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
    <Issuer>http://WS2012R2-0.contoso.com/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="https://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
        <ds:SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <ds:Reference URI="#_7e3c1bcd-f180-4f78-83e1-7680920793aa">
          <ds:Transforms>
            <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#enveloped-signature" />
            <ds:Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
          </ds:Transforms>
          <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
          <ds:DigestValue>CBn/aB1cD2eF3gH4iJ5kL6-mN7oP8qR=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>cD2eF3gH4iJ5kL6mN7-oP8qR9sT==</ds:SignatureValue>
      <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</ds:X509Certificate>
        </ds:X509Data>
      </KeyInfo>
    </ds:Signature>
    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEG1234567890</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <SubjectConfirmationData InResponseTo="_049917a6-1183-42fd-a190-1d2cbaf9b144" NotOnOrAfter="2014-01-31T15:41:31.357Z" Recipient="https://login.partner.microsoftonline.cn/login.srf" />
      </SubjectConfirmation>
    </Subject>
    <Conditions NotBefore="2014-01-31T15:36:31.263Z" NotOnOrAfter="2014-01-31T16:36:31.263Z">
      <AudienceRestriction>
        <Audience>urn:federation:partner.microsoftonline.cn</Audience>
      </AudienceRestriction>
    </Conditions>
    <AttributeStatement>
      <Attribute Name="IDPEmail">
        <AttributeValue>administrator@contoso.com</AttributeValue>
      </Attribute>
    </AttributeStatement>
    <AuthnStatement AuthnInstant="2014-01-31T15:36:30.200Z" SessionIndex="_7e3c1bcd-f180-4f78-83e1-7680920793aa">
      <AuthnContext>
        <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
    </AuthnStatement>
    </Assertion>
    </samlp:Response>

配置兼容 SAML 2.0 的标识提供者

本部分包含的指南涉及如何配置 SAML 2.0 标识提供者以联合 Microsoft Entra ID 进行身份验证，从而使用 SAML 2.0 协议启用通过单一登录访问一个或多个 Azure 云服务（例如 Microsoft 365）的功能。此方案中使用的 Azure 云服务的 SAML 2.0 信赖方为 Microsoft Entra ID。

添加 Microsoft Entra 元数据

SAML 2.0 标识提供者需要遵循有关 Microsoft Entra ID 信赖方的信息。 Microsoft Entra ID 在 https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml 发布元数据。

建议在配置 SAML 2.0 标识提供者时，始终导入最新的 Microsoft Entra 元数据。

注意

Microsoft Entra ID 不会从标识提供者读取元数据。

将 Microsoft Entra ID 添加为信赖方

必须启用 SAML 2.0 标识提供者与 Microsoft Entra ID 之间的通信。此配置取决于特定的标识提供者，应参考标识提供者的文档。通常需要将信赖方 ID 与 Microsoft Entra 元数据的 entityID 设置为相同。

注意

请验证 SAML 2.0 标识提供者服务器上的时钟是否已与准确的时间源同步。时钟的时间不准确可能导致联合身份验证登录失败。

安装 PowerShell 以使用 SAML 2.0 标识提供者登录

配置了用于 Microsoft Entra 登录的 SAML 2.0 标识提供者后，下一步是下载并安装 Microsoft Graph PowerShell 模块。安装后，你将使用这些 cmdlet 将 Microsoft Entra 域配置为联合域。

下载 Microsoft Graph PowerShell 模块是为了管理 Microsoft Entra ID 中的组织数据。此模块会将一组 cmdlet 安装到 PowerShell，你运行这些 cmdlet 以设置到 Microsoft Entra ID 的单一登录访问，并由此延伸到你订阅的所有云服务。有关如何下载和安装 cmdlet 的说明，请参阅安装 Microsoft Graph PowerShell SDK。

在 SAML 标识提供者和 Microsoft Entra ID 之间设置信任

在 Microsoft Entra 域上配置联合前，必须先配置自定义域。无法联合 Microsoft 提供的默认域。 Microsoft 的默认域以 partner.onmschina.cn 结尾。若要为单一登录添加或转换域，需要运行一系列 PowerShell cmdlet。

希望使用 SAML 2.0 标识提供者进行联合的每一个 Microsoft Entra 域都必须添加为单一登录域，或者从标准域转换为单一登录域。添加或转换域时将在 SAML 2.0 标识提供者和 Microsoft Entra ID 之间设置信任。

以下过程演示如何使用 SAML 2.0 SP-Lite 将现有的标准域转换为联合身份验证域。

注意

执行这一步后，域可能会遇到服务中断而影响用户，最长可持续 2 小时。

在 Microsoft Entra Directory 中配置联合域以进行联合

以租户管理员身份连接到 Microsoft Entra Directory：

Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -Scopes "Domain.ReadWrite.All"

通过 SAML 2.0 将所需的 Microsoft 365 域配置为使用联合身份验证：

$Domain = "contoso.com"  
$LogOnUrl = "https://WS2012R2-0.contoso.com/passiveLogon" 
$LogOffUrl = "https://WS2012R2-0.contoso.com/passiveLogOff" 
$ecpUrl = "https://WS2012R2-0.contoso.com/PAOS" 
$MyUri = "urn:uri:MySamlp2IDP"
$idptokensigningcert = [System.Security.Cryptography.X509Certificates.X509Certificate2]("C:\temp\contosoidptokensign.cer")  
$MySigningCert = [system.convert]::tobase64string($idptokensigningcert.rawdata) 
$Protocol = "saml"

New-MgDomainFederationConfiguration `
  -DomainId $Domain `
  -ActiveSignInUri $ecpUrl `
  -IssuerUri $MyUri `
  -PassiveSignInUri $LogOnUrl `
  -PreferredAuthenticationProtocol $Protocol `
  -SignOutUri $LogOffUrl `
  -SigningCertificate $MySigningCert

可以从 IDP 元数据文件中获取签名证书的 base64 编码字符串。下面提供了此位置的示例，但根据你的实现，情况会略有不同。

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="signing">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
     <X509Data>
       <X509Certificate> eF3gH4iJ5kL6mN7oP8-qR9sT0uV=</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
</IDPSSODescriptor>

有关详细信息，请参阅 New-MgDomainFederationConfiguration。

注意

仅当为标识提供者设置了 ECP 扩展时，才必须使用 $ecpUrl = "https://WS2012R2-0.contoso.com/PAOS"。除 Outlook Web Application (OWA) 之外的 Exchange Online 客户端依赖于基于 POST 的活动终结点。如果 SAML 2.0 STS 实现的活动终结点类似于 Shibboleth 对活动终结点的 ECP 实现，则这些富客户端可能会与 Exchange Online 服务交互。

配置了联合后，可切回“非联合”（或“托管”），但是此更改需要最长两个小时才能完成，并且需要为每个用户分配新的随机密码以用于基于云的登录。在某些情况下，可能需切换回“托管”模式才能在设置中重置错误。有关域转换的详细信息，请参阅 Remove-MgDomainFederationConfiguration。

将用户主体预配到 Microsoft Entra ID/Microsoft 365

向 Microsoft 365 进行用户身份验证之前，必须根据 SAML 2.0 声明中的断言语句为 Microsoft Entra ID 预配用户主体。如果 Microsoft Entra ID 事先无法识别这些用户主体，则它们无法用于联合登录。 Microsoft Entra Connect 或 PowerShell 都可以用来预配用户主体。

可以使用 Microsoft Entra Connect 将主体从本地 Active Directory 预配到 Microsoft Entra Directory 的域中。有关详细信息，请参阅将本地目录与 Microsoft Entra ID 集成。

还可以使用 PowerShell 自动向 Microsoft Entra ID 添加新用户以及从本地目录同步更改。若要使用 PowerShell cmdlet，必须下载 Microsoft Graph PowerShell 模块。

此过程演示如何向 Microsoft Entra ID 添加单个用户。

使用 Connect-MgGraph 以租户管理员身份连接到你的 Microsoft Entra Directory。

创建新用户主体：

$Password =  -join ((48..57) + (97..122) | Get-Random -Count 12 | % {[char]$_})
$PasswordProfile = @{ Password = "$Password" }

New-MgUser `
  -UserPrincipalName "elwoodf1@contoso.com" `
  -DisplayName "Elwood Folk" `
  -GivenName "Elwood" `
  -Surname "Folk" `
  -AccountEnabled `
  -MailNickName 'ElwoodFolk' `
  -OnPremisesImmutableId ABCDEFG1234567890 `
  -OtherMails "Elwood.Folk@contoso.com" `
  -PasswordProfile $PasswordProfile `
  -UsageLocation "CN"

有关详细信息，请参阅 New-MgUser。

注意

“UserPrincipalName”值必须与将在 SAML 2.0 声明中为“IDPEmail”发送的值匹配，“OnPremisesImmutableId”值必须与在“NameID”断言中发送的值匹配。

通过 SAML 2.0 IDP 验证单一登录

在以管理员身份验证和管理单一登录（也称联合身份验证）之前，请查看以下文章中的信息并执行相关步骤，以便通过基于 SAML 2.0 SP-Lite 的标识提供者设置单一登录：

已查看 Microsoft Entra SAML 2.0 协议需求
配置 SAML 2.0 标识提供者
安装 PowerShell 以使用 SAML 2.0 标识提供者进行单一登录 (SSO)
在 SAML 2.0 标识提供者和 Microsoft Entra ID 之间设置信任
通过 PowerShell 或 Microsoft Entra Connect 预配了 Microsoft Entra ID (Microsoft 365) 的已知测试用户主体。
使用 Microsoft Entra Connect 配置目录同步。

通过基于 SAML 2.0 SP-Lite 的标识提供者设置 SSO 后，应验证是否能够正确工作。

注意

如果转换而不是添加域，则可能需要长达 24 小时来设置单一登录。在验证单一登录之前，应完成 Active Directory 同步的设置，对目录进行同步，并激活同步的用户。

手动验证单一登录是否已正确设置

手动验证提供了其他步骤可供采取，以此确保 SAML 2.0 标识提供者在许多方案中都能正常工作。若要验证是否已正确设置单一登录，请完成以下步骤：

在已加入域的计算机上，使用用于公司凭据的相同登录名登录到云服务。
在密码框内选择。如果设置了单一登录，密码框将会灰显，并且你将看到以下消息：“你现在需要在<你的公司>登录。”
选择“在<你的公司>登录”链接。如果你能够登录，则单一登录已设置成功。

通过