Question

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

我们的假设。

IDP = StackOverflow大学
SP =我们的申请

我们的客户已向我们索取以下信息

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

我们不是InCommon的成员。

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

移动客户端会打开网页浏览并导航到特定网络地址。该Web地址将创建登录屏幕。我们如何配置请求使用以下这些网址之一和AuthnRequest？

＆＃13;

<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"/>

＆＃13;

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

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

Answer 1

客户端，您需要SAML stack。

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

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

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

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

Answer 2

我不确定我是否正确理解了用例，但是我认为移动客户端不应该执行任何实际的SAML处理；发生在服务提供商（SP）和身份提供商（IdP）之间。实际上，在这种情况下，OpenID Connect会更适合。但是，仅出于说明目的（在必须使用SAML的情况下），简而言之就是：

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

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

Saml SSO与移动客户端

2 个答案: