我正在尝试获得 SAML 断言，但我有一个使用我的 MSDN 积分的简单 Microsoft Azure 帐户 - 没有 ADFS - 我想尝试一下。 我可以使用 login.microsoft.com/_TenantId/SAML2?SAMLRequest API 获得 SAML 响应，但是当我将 SAML 响应作为“断言”放在对“OAuth2/v2.0/Token”的调用中时，我每次都会收到错误：AADSTS50107：请求的联合领域对象“ https://sts.windows.net/_TenantID_/ ”不存在。
如何在没有 ADFS 的情况下获得 SAML 断言？
文件详情
⚠请勿编辑此部分。
- 编号：9f168986-8f8f-4e97-cba8-547564c97eb5
- 版本独立 ID：12ac4571-4f35-300e-9119-8d13673f3722
- 内容： Microsoft 身份平台和 SAML 不记名声明流程
- 内容来源： articles/active-directory/develop/v2-saml-bearer-assertion.md
- 服务：活动目录
- 子服务：开发
- GitHub 登录：@umeshbarapatre
- 微软别名： ryanwi
keithdv
所有41条评论
@keithdv感谢您的反馈！ 我们将酌情进行调查和更新。
FrankHu-MSFT
于 2019-12-20
@keithdv ，我为我的回复延迟道歉。 我确实检查了线程，并且真的很想了解有关为什么我们试图从我们计划从那里获取令牌的同一 IDP 生成 SAML 断言的更多详细信息。
我宁愿去 OAuth2.0 的授权代码授予流程并获取访问令牌。 我不确定这是否应该起作用。
我已经用 ADFS 测试了这个流程，它工作正常。 如果您想获得相同的步骤，请告诉我，以便我可以与您分享。
另外，如果您计划按照您在查询中提到的路线行驶，请随时让我知道是否有一定的要求/限制，以便更好地了解您的实际要求，我们可以进行更多研究并分享一些更多有用的信息。
souravmishra-msft
于 2019-12-30
嗨，基思，
要获得 SAML 断言，您需要有一个 IDP，即与 Azure 活动目录联合的身份提供者。 我使用 ADFS 和另外一个第三方身份提供商对此进行了测试。 任何支持 SAML 2.0 令牌的 IDP 都应该使用它。 希望这可以帮助 ！
谢谢
乌梅什
来自：Keith Voels [mailto:[email protected]]
发送时间：2019 年 12 月 21 日 02:44
至：MicrosoftDocs/azure-docs [email protected]
抄送：Umesh B [email protected] ； 提及[email protected]
主题：[MicrosoftDocs/azure-docs] 如何在没有 ADFS 的情况下获得 SAML 断言 (#45071)
我正在尝试获得 SAML 断言，但我有一个使用我的 MSDN 积分的简单 Microsoft Azure 帐户 - 没有 ADFS - 我想尝试一下。 我可以使用 login.microsoft.com/_TenantId/SAML2?SAMLRequest API 获得 SAML 响应，但是当我将 SAML 响应作为“断言”放在对“OAuth2/v2.0/Token”的调用中时，我每次都会收到错误：AADSTS50107：请求的联合领域对象“ https://sts.windows.net/_TenantID_/ ”不存在。
如何在没有 ADFS 的情况下获得 SAML 断言？
文件详情
⚠ 请勿编辑此部分。 它是 docs.microsoft.com ➟ GitHub 问题链接所必需的。
- 编号：9f168986-8f8f-4e97-cba8-547564c97eb5
- 版本独立 ID：12ac4571-4f35-300e-9119-8d13673f3722
- 内容：Microsoft 身份平台和 SAML 不记名声明流程https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-saml-bearer-assertion
- 内容来源：articles/active-directory/develop/v2-saml-bearer-assertion.md https://github.com/Microsoft/azure-docs/blob/master/articles/active-directory/develop/v2-saml-不记名断言.md
- 服务：活动目录
- 子服务：开发
- GitHub 登录：@umeshbarapatre https://github.com/umeshbarapatre
- 微软别名：ryanwi
—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWIKJA5AXT7NQUZAORTQZUYRTA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ICCC32A ，或退订https://github.com/notifications/unsubscribe-auth/ AKCNYWOJY4YS73T4J7OTRWDQZUYRTANCNFSM4J6CXN2Q 。
umeshbarapatre
于 2019-12-30
1.0 版（oauth/token）就是这样做的。
“通过 OAuth2.0 OBO 流获得的 SAML 断言”
https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow#saml -assertions-obtained-with-an-oauth20-obo-flow
对于其他任何人......我会忽略这篇文章并查看上面的链接。
keithdv
于 2019-12-30
嗨，基思，
您能帮我了解您想要获取 SAML 断言的场景吗？ SAML 不记名声明流程使用有效的 OAuth 令牌提供给任何 IDP，以在相同的基础上提供 SAML 声明。 这个概念与 SAP 和 salesforce 等其他平台类似。 OBO 流程是出于不同的原因，我想了解更多有关最终目标是什么的详细信息。
umeshbarapatre
于 2020-01-01
@keithdv ，想检查以下几点：
- 从 AzureAD 收到的 SAML 请求和 SAML 响应是什么？
- 您是否刚刚从 SAML 响应中复制了断言部分 (
<assertion>....</assertion>)，然后在将响应提供给 AAD 的令牌端点之前对其进行了 URL 编码？
请按照@umeshbarapatre 的要求，让我知道以下查询的答案以及最终目标，以便我们更好地为您提供帮助。
souravmishra-msft
于 2020-01-02
@keithdv ，关于这种情况有一些有趣的事实。 此过程应该仅适用于联合域，而不适用于托管域，因为 IDP（在托管域的情况下）共享的响应不受同一 IDP 的信任，因为托管域不属于 Azure Trusted域列表。 在 Azure 的受信任域列表中，只有联合域是其中的一部分。
希望这可以帮助。
souravmishra-msft
于 2020-01-03
@souravmishra-msft - 是的，没错。 SAML 不记名断言流程适用于与受管域不同的联合域。 因此，我询问了我们在此测试中尝试实现的目标。
umeshbarapatre
于 2020-01-03
这是我们需要的。 我们的应用程序正在调用 Azure AD 注册和受保护的 API。 然后，该 Azure API 调用 SAP 注册和受保护的 API。 SAP 联合到 Azure AD。 我们不希望应用程序知道 SAP 或直接调用 SAP。
因此，我们需要在 Azure API 内进行令牌交换：将 Azure 不记名令牌交换为 SAP 不记名令牌，同时保留身份。 由于涉及两个服务提供商（Azure 和 SAP），我们无法交换 OAuth2 令牌，我们需要交换 SAML 令牌——SAML 断言。 这在 API 中，所以它不能是浏览器功能。
v1 端点很好地支持这一点。 您可以将 Azure API 的访问令牌发送到“oauth/token”并获得 SAML 断言。 然后我们将 SAML 断言发送到 SAP 并获取调用 SAP API 所需的访问令牌（请参阅下面的链接）。 我们需要一个“grant_ type:jwt-bearer ”到“token- type:saml2 ”在 V2 中，就像今天在 V1 中存在的一样。
https://wiki.scn.sap.com/wiki/display/Security/Using+OAuth+2.0+from+a+Web+Application+with+SAML+Bearer+Assertion+Flow
我并不孤单，请查看评论： https :
我已经通读了所有 Microsoft 文档，但从未见过关于“托管域”与“联合域”的任何讨论。 我不知道“托管域”指的是什么。
keithdv
于 2020-01-03
嗯，这正是我们想知道的。 当我们使用相同的 SAP 场景和您在执行 POC 时提到的 SAP 文章进行测试时，也发布了本文。 唯一的区别是，在这种情况下，AAD 和 SAP 已与第三方 IDP（即 ADFS）联合，但它可以是任何其他 IDP。 因此，这建议调用 ADFS 端点来获取 SAML 断言。 在您的情况下，AAD 充当第一方 IDP，您正在调用 AAD oAuth 端点 v1 以获取 saml 断言（尽管我们可以测试并更新它作为评论）。 获得 SAML 断言后，您将相同的断言呈现给 SAP oAuth 令牌端点以获取 SAP Oauth 令牌并从 SAP 端调用任何所需的 api。 所以简而言之，承载流保持不变。 但是，我会检查 V1 评论以进行更新。 这并不意味着 AAD 只能作为 IDP 工作，即使 ADFS 将成为传统，世界其他地方也使用了许多其他 IDP。 还有很多其他的 3rd 方 idp，许多公司都在使用，如 Oracle IDM、Vmware IDM 等。希望这些信息对您有所帮助！
谢谢
乌梅什
来自：Keith Voels [mailto:[email protected]]
发送：2020 年 1 月 3 日 22:21
至：MicrosoftDocs/azure-docs [email protected]
抄送：Umesh B [email protected] ； 提及[email protected]
主题：回复：[MicrosoftDocs/azure-docs] 如何在没有 ADFS 的情况下获得 SAML 断言 (#45071)
这是我们需要的。 我们的应用程序正在调用 Azure AD 注册和受保护的 API。 然后，该 Azure API 调用 SAP 注册和受保护的 API。 SAP 联合到 Azure AD。 我们不希望应用程序知道 SAP 或直接调用 SAP。
因此，我们需要在 Azure API 内进行令牌交换：将 Azure 不记名令牌交换为 SAP 不记名令牌，同时保留身份。 由于涉及两个服务提供商（Azure 和 SAP），我们无法交换 OAuth2 令牌，我们需要交换 SAML 令牌——SAML 断言。 这在 API 中，所以它不能是浏览器功能。
v1 端点很好地支持这一点。 您可以将 Azure API 的访问令牌发送到“oauth/token”并获得 SAML 断言。 然后我们将 SAML 断言发送到 SAP 并获取调用 SAP API 所需的访问令牌（请参阅下面的链接）。 我们需要一个“grant_ type:jwt-bearer ”到“token- type:saml2 ”在 V2 中，就像今天在 V1 中存在的一样。
https://wiki.scn.sap.com/wiki/display/Security/Using+OAuth+2.0+from+a+Web+Application+with+SAML+Bearer+Assertion+Flow
我并不孤单，请查看评论： https :
我已经通读了所有 Microsoft 文档，但从未见过关于“托管域”与“联合域”的任何讨论。 我不知道“托管域”指的是什么。
—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWLXEV5ME6XAZFPST6TQ35UJDA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIBR5VQ#issuecomment-570629846 ，或退订https://github.com/notifications/取消订阅身份验证/AKCNYWJUJ7FN6NV43FM2D2DQ35UJDANCNFSM4J6CXN2Q 。
umeshbarapatre
于 2020-01-03
对不起，但这里的解释并没有真正让我变得更聪明。 我现在有点悬而未决，所以如果有人能解释一下需要做的事情，那就太好了。
我已经在 Azure Active Directory 和 SAP Cloud Platform 之间设置了 SSO。 通过 Azure AD 登录到 SAP Cloud Platform 后，我收到了 SAML 响应。 我用 BASE64 加密了 SAML 响应的断言部分。 然后我将其发送到令牌端点 (v2)。 在那里我还收到错误消息“AADSTS50107：请求的联合领域对象” https://sts.windows.net/_TenantID_/ “不存在”。
是否已为此找到解决方案？ 或者我们基本上做错了什么？
Noirde
于 2020-01-05
@noirde你很接近。 你和我走的路是一样的。 我实际上还没有在我正在等待访问的企业中尝试使用 SAP 的 Azure SAML 断言。 一旦我这样做，我担心我会犯同样的错误。 当您尝试将 SAML 断言与 Microsoft Graph 结合使用时，您会遇到同样的错误。 请参阅有关错误的关闭评论。
一个我有权限我会告诉你我们是否成功。
keithdv
于 2020-01-06
嗨，基思，
您能否分享您在调用 azure v1 端点时收到的示例断言信封。 那是一个 samlp 信封断言吗？
谢谢
乌梅什
来自：Keith Voels [mailto:[email protected]]
发送：2020 年 1 月 6 日 08:58
至：MicrosoftDocs/azure-docs [email protected]
抄送：Umesh B [email protected] ； 提及[email protected]
主题：回复：[MicrosoftDocs/azure-docs] 如何在没有 ADFS 的情况下获得 SAML 断言 (#45071)
@Noirde https://github.com/Noirde你很接近。 你和我走的路是一样的。 我实际上还没有在我正在等待访问的企业中尝试使用 SAP 的 Azure SAML 断言。 一旦我这样做，我担心我会犯同样的错误。 当您尝试将 SAML 断言与 Microsoft Graph 结合使用时，您会遇到同样的错误。 请参阅有关错误的关闭评论。
一个我有权限我会告诉你我们是否成功。
—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWMSMKAXIUX3T2CF7BTQ4KQNDA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIEJYAI#issuecomment-570989569 ，或退订https://github.com/notifications/取消订阅身份验证/AKCNYWOPER7HLDULIQQHV63Q4KQNDANCNFSM4J6CXN2Q 。
umeshbarapatre
于 2020-01-06
嗨乌梅什，
干得好。 我不相信。 这只是<Assertion>
<Assertion ID="_32e7b830-43cf-40cd-a0f7-0ddf851dfb00" IssueInstant="2020-01-06T22:03:57.551Z" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://sts.windows.net/cb632b2c-217b-4edd-9be9-35f29b5c9f11/</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/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_32e7b830-43cf-40cd-a0f7-0ddf851dfb00">
<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/2001/04/xmlenc#sha256"/>
<DigestValue>Ng1WJ0mjixtBOAflWvZUX10duf7bmjHV7DGIyQDiABs=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>BbHkH/aXuejrSDoWHuBXbXWVyF8aU1O1ZMtCaJwgvrvjBjuA8Go9P7y+maryiQXk0+o/6jv5GciNkYaatAcIl8XpHetUvs6VRtEbqleE0n80LY/eSV7fDmhRYnq7YlH/d3lEmMInsEE2q0WxX/9hxvpADlTt6x1zF7QvCSmQl5nlBEvYuPXqhKgLNtCbBykwu+CHHfcP+ULBJZkZJp12wbV00yPJxlrOYSvszKLmvwaBqWNqxjmuKUADNnHnbHZWr2UbsuBiBn2fIOTg6AFhl7JktI/vMMr35wJJkJTDWvq8CknJxFHxGKUspCGHtI0nNOCUhBaiCw3q4LcKylpOlw==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIDBTCCAe2gAwIBAgIQMCJcgWf4l5xPpeoEwB7DKDANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJhY2NvdW50cy5hY2Nlc3Njb250cm9sLndpbmRvd3MubmV0MB4XDTE5MTExNTAwMDAwMFoXDTI0MTExNDAwMDAwMFowLTErMCkGA1UEAxMiYWNjb3VudHMuYWNjZXNzY29udHJvbC53aW5kb3dzLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANF4YcKZhKTfowwWqZ84RW7bxFNgaSy3Gi85V5uJpU9jMCmZV0VFGptryNFEQ1GESmmuDutgQlkkhjr9ixkOrTA+aFPg6pLn+OG6NYS7nyKgAC1MprLH0bq06y3dH6lQPWQhd3wPP+8UIua9+9JuIfhu9Xs/HhN5cYlT5cEniV0aWuUMxgPAKcG1xolfupYhlOHjFwVN/QOaxcuk3YqGguD+sZ7PiHcJSzFnTkdvD+DtMoW1U6nDf5FuDeAEKJ7JQf7RjiRoViYxZHKrEPHG4iZ+kOhV6DQA16ISTt7ALXVB8gTTF3OvItubk2E3v6sgirgtvdE5Mkd4MTJcO67bgdUCAwEAAaMhMB8wHQYDVR0OBBYEFEXiTeLGkA2LgAjQOrT2KChpgwCgMA0GCSqGSIb3DQEBCwUAA4IBAQA6GqtYZDQzym0yxfL2NnlSbJP/lLhSQOqbPBdN6DWQ/3duk+e08Ix5qy63hzW+qQR0PAkFEcooL5+bdheS66tFJpVejEcqCSKUVvwOUe6GY/ju752dlB7anBB9An362khehCxqydYNS5Igl0rtcP7dKC3ZBn1m2B9ULsyx46iNpfHQHHv9NKU2vVq2CtNc95CFktwjUwlyWMgbfI/DzPX/cC6KnglqsuVVBO7+jIaBmi0XGqudooZkqgIrvnfNMM13Gy78TUNHsCiAQEwZ/L17yNbzotNGxAoPfuXldbD52MQNOsA7WhH+j8qFWY6gZzTN4NpVtuW4m04TCEFexnTz</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ftOmbYBIMVgi3RWFQa2lLAqkmtzBAdZXJjrcQVo5KR0</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
</Subject>
<Conditions NotBefore="2020-01-06T21:58:57.207Z" NotOnOrAfter="2020-01-06T23:03:27.207Z">
<AudienceRestriction>
<Audience>https://ebs.sap.com/sap/bc/sec/oauth2/token</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>cb632b2c-217b-4edd-9be9-35f29b5c9f11</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>af56d9be-a146-4230-801e-f83f1a3bab4e</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
<AttributeValue>Voels</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
<AttributeValue>Keith</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
<AttributeValue>Keith Voels</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>live.com</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/unspecified</AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2020-01-06T22:03:07.208Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
keithdv
于 2020-01-06
我的略有不同。 尤其是我的身份提供者不是live.com，而是sts.../
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_718927ef-7105-4baa-84c5-74b8b0b46600"
IssueInstant="2020-01-07T09:22:48.487Z"
Version="2.0"
>
<Issuer>https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/</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/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="#_718927ef-7105-4baa-84c5-74b8b0b46600">
<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/2001/04/xmlenc#sha256" />
<DigestValue><Value></DigestValue>
</Reference>
</SignedInfo>
<SignatureValue><Value></SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate><Value></X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"><Value></NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData InResponseTo="a883788fahf73ai48ee64e660g4fe8"
NotOnOrAfter="2020-01-07T10:22:48.268Z"
Recipient="<value>"
/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2020-01-07T09:17:48.268Z"
NotOnOrAfter="2020-01-07T10:22:48.268Z"
>
<AudienceRestriction>
<Audience>https://<Value>.authentication.eu10.hana.ondemand.com</Audience>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
<Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
<AttributeValue>32b337ff-9459-4bc1-b28a-b720735cbe39</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
<AttributeValue>113b9583-05a6-4867-90f2-1ab4d1ef7225</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
<AttributeValue>https://sts.windows.net/32b337ff-9459-4bc1-b28a-b720735cbe39/</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
<AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
</Attribute>
<Attribute Name="first_name">
<AttributeValue><Value></AttributeValue>
</Attribute>
<Attribute Name="last_name">
<AttributeValue><Value></AttributeValue>
</Attribute>
<Attribute Name="mail">
<AttributeValue><Value></AttributeValue>
</Attribute>
<Attribute Name="Groups">
<AttributeValue><Value></AttributeValue>
</Attribute>
</AttributeStatement>
<AuthnStatement AuthnInstant="2020-01-07T09:22:46.413Z"
SessionIndex="_718927ef-7105-4baa-84c5-74b8b0b46600"
>
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
Noirde
于 2020-01-07
谢谢基思。几个问题。 sap oauth token 是否接受此断言。 我看不到名字 Id 可能是我正在阅读它
来自移动设备，但这是其中之一
强制属性。 让我知道我们是否可以在某个时候联系
获取 iOS 版 Outlook https://aka.ms/o0ukef
来自：Keith Voels [email protected]
发送时间：2020 年 1 月 7 日，星期二 3:39:53 AM
至：MicrosoftDocs/azure-docs [email protected]
抄送：Umesh B [email protected] ； 提及[email protected]
主题：回复：[MicrosoftDocs/azure-docs] 如何在没有 ADFS 的情况下获得 SAML 断言 (#45071)
嗨乌梅什，
干得好。 我不相信。 简直就是
—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWICCZVPVAWOMG5QTI3Q4OT3DA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIG6VLA#issuecomment-571337388 ，或退订https://github.com/notifications/取消订阅身份验证/AKCNYWN7ATHP2NQHI3NUYHTQ4OT3DANCNFSM4J6CXN2Q 。
umeshbarapatre
于 2020-01-08
关于基思的帖子有
我猜基思正在做一些与我非常相似的事情，但不知何故反对 v1 而不是 v2。 为了进行测试，我采用了通过 Azure AD 成功登录 SAP Cloud Platform 后返回的断言。 我通过https://www.base64encode.org/手动将其转换为 base64。
现在我正在尝试将正文发布到“ https://login.microsoftonline.com/ {{TenantID}}/oauth2/v2.0/token”：
grant_type:urn:ietf:params:oauth:grant-type:saml2-bearer
client_id:{{ClientID}}
client_secret:{{ClientSecret}}
scope:https://graph.microsoft.com/.default
assertion:{{Base64_encoded_assertion}}
现在我收到了上述错误：
{
"error": "invalid_request",
"error_description": "AADSTS50107: The requested federation realm object 'https://sts.windows.net/<tenantId>/' does not exist.\r\nTrace ID: 6365a830-7aa3-4b27-94cc-7b3d31d09a00\r\nCorrelation ID: 5f89f618-58d2-4f4a-9e90-fcf3d7ca6762\r\nTimestamp: 2020-01-10 17:24:49Z",
"error_codes": [
50107
],
"timestamp": "2020-01-10 17:24:49Z",
"trace_id": "6365a830-7aa3-4b27-94cc-7b3d31d09a00",
"correlation_id": "5f89f618-58d2-4f4a-9e90-fcf3d7ca6762",
"error_uri": "https://login.microsoftonline.com/error?code=50107"
}
Noirde
于 2020-01-10
@noirde我多次遇到该错误，但没有解决。 我无法让 Microsoft Graph 接受 SAML 断言以在任何场景中获取访问令牌。
@umeshbarapatre是的，我们已经让 SAP 接受 SAML 断言。 我们不得不在 Azure 企业应用程序设置中使用 NameID 属性、AudienceRestriction 和 Recipient，但我们让它起作用了。
是的，我非常想联系。 请给我发电子邮件。 谢谢！
keithdv
于 2020-01-20
任何更新或进一步的提示？
Noirde
于 2020-01-26
嗨，基思，
抱歉，我有点忙于日常职责。 您在哪个时区工作。 我们可以在 2 月 4 日星期二的某个时间通过 Skype 连接。
谢谢
乌梅什
来自：Keith Voels [mailto:[email protected]]
发送时间：2020 年 1 月 21 日 03:14
至：MicrosoftDocs/azure-docs [email protected]
抄送：Umesh B [email protected] ； 提及[email protected]
主题：回复：[MicrosoftDocs/azure-docs] 如何在没有 ADFS 的情况下获得 SAML 断言 (#45071)
@Noirde https://github.com/Noirde我多次遇到该错误，但没有解决。 我无法让 Microsoft Graph 接受 SAML 断言以在任何场景中获取访问令牌。
@umeshbarapatre https://github.com/umeshbarapatre是的，我们已经让 SAP 接受 SAML 断言。 我们不得不在 Azure 企业应用程序设置中使用 NameID 属性、AudienceRestriction 和 Recipient，但我们让它起作用了。
是的，我非常想联系。 请给我发电子邮件。 谢谢！
—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/MicrosoftDocs/azure-docs/issues/45071?email_source=notifications&email_token=AKCNYWOEA27GFBJVMY62W5TQ6YLKPA5CNFSM4J6CXN22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJN4FIA#issuecomment-576438944 ，或退订https://github.com/notifications/取消订阅身份验证/AKCNYWMYS3GU3G5LFK3URCLQ6YLKPANCNFSM4J6CXN2Q 。
umeshbarapatre
于 2020-02-01
你能推导出解决方案吗？
Noirde
于 2020-02-05
@keithdv - 很高兴听到 NameID 和其他属性对您
umeshbarapatre
于 2020-02-06
你能推导出解决方案吗？
@Noirde - 由于 Keith 确认 SAML 断言成功，我们领先一步，我可以根据提供的信息帮助接受 Graph API
umeshbarapatre
于 2020-02-06
@umeshbarapatre - 我有一个不同的授权场景，我正在尝试确定我是否可以使用 SAML 断言到 OAuth2 不记名令牌流，或者该线程是否说它不起作用。 在我的情况下，我使用 SAML2 SSO 到 3rd 方应用程序，AzureAD 作为 IdP……这是有效的，但我想获得一个 OAUTH 不记名令牌来调用 Microsoft 图形（与 AzureAD 相同的租户）以将 3rd 方应用程序集成到 Office 365。我仍在进行测试，但这个线程让我对这是否应该/不应该工作感到困惑。 任何帮助表示赞赏。
Khyzdul
于 2020-03-23
因此，我已经到了 login.microsoftonline.com/tenant-id/OAuth2/v2.0/token 接受 Azure AD 发布的 SAML 断言的地步，但是我得到了与您相同的错误：
AADSTS50107：请求的联合领域对象“ https://sts.windows.net/tenant-id/ ”不存在。
我要求以下授权类型：“ urn:ietf : params:oauth :grant- type:saml2-bearer ”以访问与 SAML 断言相同领域中的图形 API。
当我从 powershell 对我们的租户运行此查询时：
Get-MsolDomainFederationSettings
结果是空的。
一些供应商文章，例如来自 SecureAuth 的这篇文章：
暗示发行人需要出现在此命令的输出中？
Khyzdul
于 2020-04-03
@Khyzdul我从来没有让 Microsoft Graph API 接受记录的 SAML 断言。 我被你遇到的错误困住了。 在 Azure 中坚持使用 OAuth2 令牌。
我们所做的是其他供应商（MuleSoft、SAP）将接受 Azure SAML 断言以获取用户特定的 OAuth2 不记名令牌。
对我来说这是合乎逻辑的。 OAuth2 并不意味着涉及多个身份提供者。 SAML 是； 这就是它的作用。 因此，在跳转身份提供者时使用 SAML 断言。 在单个身份提供者中不要使用 SAML 断言。
keithdv
于 2020-04-09
@keithdv虽然您所说的 SAML 和 OAuth2 的差异是真的，但我认为还有另外两个方面。 一个是 SAML 用于一些尚未在后面实现 OAuth 的旧遗留系统（然后能够重用这部分并将断言用于其他事情会很好），第二个（更重要的是，恕我直言），人们会/可以假设，当向“AAD 租户”询问 SAML 断言，然后从同一个 AAD 租户处获取令牌时，不需要任何联合？ 我理解我们收到此错误的技术原因，但从用户/逻辑的角度来看，这没有多大意义......你不同意吗？ （现在基本上是说“我们不信任我们自己的域”）
wimvanhouts
于 2020-04-10
@Khyzdul - 我可以知道在您的情况下是否有特定的需要使用 SAML 路由。 我了解您仅与 Azure 联合。 您可以直接调用 OAuth 令牌端点来获取令牌，除非我遗漏了任何东西
umeshbarapatre
于 2020-04-10
@Khyzdul主要是“我们已经拥有什么”的问题。 我们有一个相当大的产品，它已经为登录过程集成了 SAML，并与 AAD 一起使用。
然而，另一个（新）模块/扩展/插件需要访问 MS Graph SDK，我们可以给它断言，但它实际上需要“交换”这个令牌（这对用户来说是不可见的）并调用Graph函数。 现在这是不可能的，因为 O365 附带的 AAD 并执行 SAML 无法将其转换为令牌，因为 Realm 未知（甚至认为它是同一个 AAD）的错误。
所以现在您确实可以争辩说我们可以使用 OAuth 重写整个登录过程，但是，在遗留产品中，这是一个合理的工作量。 这对产品有影响，因为到目前为止，它只是一个需要更改的模块，现在突然变成了严重的产品更改，以解决从用户角度来看绝对是“错误”的问题。 因此对路线图、质量保证周期、发布等的影响......
wimvanhouts
于 2020-04-12
@keithdv我们有完全相同的要求，从 AAD 获取 SAML 断言，使用它向 SAP 发送访问令牌并使用访问令牌调用 SAP API。 我已经阅读了大量文件，但仍然无法正常工作。 从上面的评论来看，你的似乎现在正在工作。 能不能分享一下步骤？ 非常感谢。
dominic1904
于 2020-05-06
我们测试了我们的理论，即我们需要将我们的租户注册为可信的联合领域（在非生产租户中这样做）。 产生的错误消息表明我们必须将租户授权模式设置为联合。
我们此时的结论是，我们将租户设置为期望由外部 IdP 处理身份验证的模式。 不知道 O365 之类的东西可能会产生什么副作用，我们不会进一步追求这一点。 我们正在重新编写应用程序以使用 Oauth。
如果 Azure AD 不信任它发出的断言，我对支持 SAML SSO（使用 Azure AD 作为 IdP）的逻辑感到困惑。
如果 MS 发布了一份 Azure AD SSO 指南，说明他们支持的模式并清楚地指出每个模式的假设/限制，那将会很有帮助。 例如，如果将 SAML 与 Azure AD 作为 IdP，则不能使用会话来调用图形 API，因为不支持令牌交换。
似乎是完全避免使用 Azure AD 作为 SAML IdP 的原因。
感谢您的精彩对话。
获取 Outlook for Android https://aka.ms/ghei36
来自：dominic1904 [email protected]
发送： 2020 年 5 月 6 日，星期三 7:55:13 AM
至：MicrosoftDocs/azure-docs [email protected]
抄送：Khyzdul [email protected] ； 提及[email protected]
主题：回复：[MicrosoftDocs/azure-docs] 如何在没有 ADFS 的情况下获得 SAML 断言 (#45071)
@keithdv https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeithdv&data=02%7C01%7C%7Ce4937829995f44b2fc3108d7f1b4566f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637243629152039847&sdata=SSCEzWzXsqKX4DeDTAVKZ4VEK5AoUsjXo4Wu8LF%2BnTM %3D&reserved=0我们有完全相同的要求，从 AAD 获取 SAML 断言，使用它发送到 SAP 以获取访问令牌并使用访问令牌调用 SAP API。 我已经阅读了大量文件，但仍然无法正常工作。 从上面的评论来看，你的似乎现在正在工作。 能不能分享一下步骤？ 非常感谢。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F45071%23issuecomment-624605575&data = 02％7C01％7C％7Ce4937829995f44b2fc3108d7f1b4566f％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637243629152049843＆SDATA = 8jUZhFplYEqm5mKPusLYAqtZxY4p3gMyMjHYQs7tSQM％3D＆保留= 0 ，或取消订阅https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub。 COM％2Fnotifications％2Funsubscribe-AUTH％2FAO5BDHYDRYGUG735YX7JQG3RQFF2DANCNFSM4J6CXN2Q＆数据= 02％7C01％7C％7Ce4937829995f44b2fc3108d7f1b4566f％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637243629152049843＆SDATA = Xzy8％2F7HUCgMjDJgKSdhyPqifGxI％2BS3Jes2GSbOEHwPU％3D＆保留= 0 。
Khyzdul
于 2020-05-07
是否有关于此主题的更新？
我处于完全相同的情况。 我在 AAD 中注册了一个 SAP C4C 企业应用程序，并且能够成功地将它用于单一登录到 SAP。
此外，我想使用完全相同的 AAD 应用程序从 AAD 请求 SAML 断言，并将其用作 OAuth SAML 承载以从 SAP 请求访问令牌。 作为@keithdv在这个问题上的开头提到的，我也是能够接收来自SAML断言login.microsoft.com/_TenantId/SAML2点，但我绝对不知道我怎么会影响Recipient的SubjectConfirmation SAML 响应中的.../sap/bc/sec/oauth2/token 。
为了澄清我的情况：
我有一个客户端应该能够执行对私有 SAP API 的请求。 因此，用户应该登录到已经与其 SAP 建立信任关系的 AAD。 从现在开始，我希望收到来自 AD 的 SAML 断言，其中 SAP 的令牌端点为recipient ，然后我可以将其与来自 SAP 的其他 OAuth 应用程序凭据一起使用以获取访问令牌。 由于此问题中的所有不同陈述以及此处提到的其他不同来源，我仍然不确定 Azure 是否可以实现这一点？ 我真的很感激任何关于这方面的建议。
michaelwolz
于 2020-07-08
重新分配：paulgarn @paulgarn抄送：@hpsin
mmacy
于 2020-07-16
GitHub 用户 umeshbarapatre 已从 MicrosoftDocs 组织中删除，因此他们作为受让人自动删除。
PRMerger6
于 2020-07-16
在此处重定向问题 #59746。
抄送： @amit17051980
krish-gh
于 2020-07-30
谢谢克里斯。
我急切地等待解决方案！
amit17051980
于 2020-07-30
产品团队确认，是的，此交换专门针对联合用户，其中应用程序从 ADFS 或其他联合 IDP 获取 SAML 令牌。 目前没有计划添加更多功能。
在大多数情况下，常规身份验证代码流可以满足这种情况（其中用户是 AAD 用户，您拥有的 SAML 令牌是从 AAD 发出的，应用程序作为受众）。 只需从 AAD 获取身份验证代码，然后从令牌端点请求图形的访问令牌。 由于用户已经登录（为了获取 SAML 令牌）。 SSO 开始生效，不需要用户重新进行身份验证。 最终结果是一样的。
krish-gh
于 2020-08-03
我们现在将继续关闭这个问题。 如果有任何后续问题或问题，请随时在此处发表评论。
krish-gh
于 2020-08-03
@krish-gh 所以不打算添加令牌端点 v1.0 中的功能（下面的链接）？？ 同样，这对我们与 SAP 和 Salesforce 通信的工作流程至关重要，如果删除此功能，我们将遇到大麻烦。 我们已经在服务层中，超出了浏览器的许多物理层。
1.0 版（oauth/token）就是这样做的。
“通过 OAuth2.0 OBO 流获得的 SAML 断言”
https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-on-behalf-of-flow#saml -assertions-obtained-with-an-oauth20-obo-flow
keithdv
于 2020-08-03
这是我们需要完成的任务的图表。 我们是集成 API 团队 - 我们不能要求浏览器应用程序进行更改。 事实上，我们不希望他们解决即使 SAP 满足请求的问题。 同样，我们可以使用 OAuth2 v1.0 令牌端点来做到这一点。
SAP OBO.pdf
keithdv
于 2020-08-03
@keithdv请在 API 工作流程的 OBO SAML 断言部分继续使用 v1.0。 没有计划从 v1 中删除它。
如前所述，目前还没有立即计划在 V2 中添加它。 我们将根据此类场景的需求进行标记。 非常感谢您分享您工作流程的详细信息。
krish-gh
于 2020-08-03
相关问题
bdcoder2
·
3评论
mrdfuse
·
3评论
AronT-TLV
·
3评论
DeepPuddles
·
3评论
ianpowell2017
·
3评论
最有用的评论
@Khyzdul主要是“我们已经拥有什么”的问题。 我们有一个相当大的产品，它已经为登录过程集成了 SAML，并与 AAD 一起使用。
然而，另一个（新）模块/扩展/插件需要访问 MS Graph SDK，我们可以给它断言，但它实际上需要“交换”这个令牌（这对用户来说是不可见的）并调用Graph函数。 现在这是不可能的，因为 O365 附带的 AAD 并执行 SAML 无法将其转换为令牌，因为 Realm 未知（甚至认为它是同一个 AAD）的错误。
所以现在您确实可以争辩说我们可以使用 OAuth 重写整个登录过程，但是，在遗留产品中，这是一个合理的工作量。 这对产品有影响，因为到目前为止，它只是一个需要更改的模块，现在突然变成了严重的产品更改，以解决从用户角度来看绝对是“错误”的问题。 因此对路线图、质量保证周期、发布等的影响......