带有移动客户端的 Saml SSO答案

【问题标题】：Saml SSO with mobile client带有移动客户端的 Saml SSO
【发布时间】：2017-12-26 15:00:53
【问题描述】：

我对 SAML 及其通过 Shibboleth 的实施有很多疑问。我已经做了相当多的研究，我想澄清一些事情。我有一个与我们的服务器通信的移动应用程序。我们的一个企业客户，我们称他们为 StackOverflow 大学，希望使用 Shibboleth（或者我应该说 SAML？）为我们的系统提供 SSO。他们已经向我们发送了所有学生的电子邮件地址和基本个人资料信息。使用 OAuth2，我们确切地知道如何提供 SSO，但是，使用 SAML，我们无法围绕 IDP、SP、AuthnRequest、元数据等。

我们的假设。

IDP = StackOverflow 大学
SP = 我们的应用程序

我们的客户要求我们提供以下信息

请让我知道下一步。我至少需要以下信息来配置我们这边： - 您的服务提供商实体 ID - 您的服务提供商元数据（如果您不是 InCommon 的成员） - 我们应该在 SAML 断言中发送给您的属性列表

我们不是 InCommon 的成员。

接近一名学生下载我们的移动应用程序。他们选择他们的机构（StackOverflow 大学）。调用我们的服务器以检索具有 SAML 必要信息的 SSO 配置。

移动客户端打开一个 web 视图并导航到一个特定的 web 地址。该网址将创建一个登录屏幕。我们如何配置请求以使用以下这些 url 和 AuthnRequest 之一？

<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://webauth.xxx.edu:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://webauth.xxx.edu:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://webauth.xxx.edu/idp/profile/Shibboleth/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://webauth.xxx.edu/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://webauth.xxx.edu/idp/profile/SAML2/Redirect/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://webauth.xxx.edu/idp/profile/SAML2/POST-SimpleSign/SSO"/>

用户输入他们的凭据
发生了我不明白的事情。
我们的服务器如何接收声明、创建令牌以及客户端使用该令牌与我们的系统进行通信。

鉴于我们的知识差距，有人可以帮助解释这个过程吗？

【问题讨论】：

定义：身份提供者（IDP）en.wikipedia.org/wiki/Identity_provider_(SAML)服务提供者（SP）en.wikipedia.org/wiki/Service_provider_(SAML)

标签： mobile single-sign-on saml saml-2.0 shibboleth

【解决方案1】：

我不确定我是否正确理解了用例，但我认为移动客户端不应该进行任何实际的 SAML 处理；这发生在服务提供者 (SP) 和身份提供者 (IdP) 之间。实际上在这样的场景中，OpenID Connect 会更适合。但只是为了解释（如果 SAML 是强制性的），简而言之就是这样：

移动应用向应用发送请求，但尚未登录；位于应用程序前面的 SP 响应重定向到 IdP。该重定向包含一个 SAML 身份验证请求。
移动应用程序必须遵循该重定向，然后执行登录。现在的问题是 SAML 没有定义登录是如何发生的；它可以是带有用户名和密码的 HTML 表单，也可以是某种 2 因素身份验证过程。如果是第一个，移动应用程序可能只是询问用户他们的凭据，然后直接发布它们，但这是一种黑客行为，并且会在 IdP 下次更改其登录表单时中断。更糟糕的是，这意味着移动应用程序实际上拥有用户的凭据，尽管它确实不应该；那些应该留在 IdP 上。这是移动应用程序中 SAML 的全部大问题。实际登录的具体执行方式未定义，取决于 IdP。
一旦登录以某种方式成功完成，IdP 将（在大多数情况下）响应 HTTP 200 和带有一些 JavaScript 代码的 XHTML 页面。该页面包含 SAML 断言，并将向服务提供商发布自身。断言没有在重定向中发回的原因是它通常太大而无法在 URL 查询参数中发送。

因此，最重要的是编写一个在传统 IdP 上执行 SAML 登录的移动客户端是一项艰巨的任务，因为这意味着移动应用程序本质上必须模仿 Web 浏览器。这是 OpenID Connect 更适合的地方，因为它具有不同的设计方法。因此，如果可能，请尝试使用 OIDC。

【讨论】：

【解决方案2】：

客户端，你需要一个SAML stack。

这将为您实施所有管道。大多数产生元数据。您将此发送给您的 IDP。这有他们要求的 entityID 等。

客户端，您将登录屏幕连接到堆栈。

您使用 IDP 元数据地址配置您的堆栈以获取其元数据。

用户单击登录，堆栈发送 AuthnRequest，IDP 显示登录屏幕，用户进行身份验证，您返回一个 SAML 令牌，其中包含 IDP 已配置返回的断言（声明）。

【讨论】：