实施SAML SSO

问题1：

我正在构建一个SaaS，我的想法是允许我的客户使用他们自己的身份验证系统登录我的应用程序。

最好的方法是什么？我将有多个客户，每个客户都可以配置SAML SSO。

答：

（1）唯一的子域分配给每个客户，例如，

customer1.your-software.com
customer2.your-software.com
customer3.your-software.com 

（2）每个客户的子域对应于具有相应SAML SP元数据的SAML SP。每个客户的SAML SP的entityID和AssertionConsumerService端点应不同。

例如，假设使用Shibboleth SAML SP，则每个客户的entityID可以是

https://customer1.your-software.com/Shibboleth.sso/Metadata
https://customer2.your-software.com/Shibboleth.sso/Metadata
https://customer3.your-software.com/Shibboleth.sso/Metadata

每个客户的AssertionConsumerService端点可以是

https://customer1.your-software.com/Shibboleth.sso/SAML2/POST
https://customer2.your-software.com/Shibboleth.sso/SAML2/POST
https://customer3.your-software.com/Shibboleth.sso/SAML2/POST

（3）每个客户都可以将其唯一的SAML SP元数据上载到他们自己的身份验证系统（即SAML IdP（身份提供者））。

基于云的SAML SP企业应用程序Salesforce已实现了上述类似的解决方案。

同样，我们为基于云的SAML IdP实现了并行解决方案，该解决方案是零密码身份验证和授权系统的一部分。

问题2：

我还担心如何最初加载用户。通常，公司会提供用户电子邮件列表，而我只是将它们批量插入数据库中，否则该帐户将没有任何用户，直到他们开始登录？

答：

由于SAML SP和SAML IdP（即您客户自己的身份验证系统）已经通过元数据交换建立了相互信任关系，因此SAML SP（随您的企业软件安装）应该信任从SAML IdP联合的所有用户信息（即客户自己的身份验证）系统）。

（1）该帐户将没有任何用户，直到他们开始登录。

（2）当新用户最初登录到您的基于云的企业应用程序时，在无法从数据库中找到用户信息之后，企业Web应用程序会将新用户信息插入数据库中。

问题3：

当用户不再是公司的一部分时，如何管理场景？公司提供停用的用户列表？

答：

（1）当用户不再是公司的一部分时，您的客户将从其身份验证系统中停用该用户。然后用户将无法登录到您的基于云的企业Web应用程序

（I）当用户访问您的基于云的企业Web应用程序时，该用户将被重定向到您客户自己的身份验证系统（即SAML IdP）。

（II）停用的用户将不会通过您客户自己的身份验证系统进行身份验证。

（III）已停用的用户将不会通过带有用户信息的SAML声明/响应重定向到基于云的企业Web应用程序。因此，停用的用户将无法登录到基于云的企业Web应用程序。

（2）您的企业Web应用程序为每个客户的IT主管为其自己的组织子域（例如customer1.your-software.com）分配管理特权。

登录到企业Web应用程序后，IT主管可以从企业Web应用程序的数据库中删除/删除/停用其组织的任何用户，例如customer1。

Okta官方网站什么是SCIM？提供有关SCIM（跨域身份管理系统）的以下说明。

When changes to identities are made in the IdP, including create, update, and delete, they are automatically synced to the SP according to the SCIM protocol.

后续问题1：

当用户通过SAML进行身份验证并重定向到回调URL（我的应用程序）时，那里的理想流程是什么？

答：

（1）使用SAML IdP进行身份验证的用户之后，该用户将重定向到企业应用程序的AssertionConsumerService URL，该URL绑定到企业应用程序的每个客户的子域。

（2）如何在GitHub存储库上使用Docker容器构建和运行Shibboleth SAML IdP和SP提供了有关使用Shibboleth SAML IdP和OpenLDAP以及SAML SP Web应用程序构建基于SAML的身份验证/授权提供程序的说明简化的企业应用程序，以允许付费用户访问受保护的Web资源）。

• Shibboleth SAML IdP负责身份联合。
• OpenLDAP负责身份验证。

您可以使用上述GitHub存储库来模拟具有多个客户及其对应的SAML IdP的SAML SP企业应用程序。

（I）在同一台物理机器/服务器（例如Ubuntu服务器）上运行三（3）个SAML SP演示应用程序docker容器（对应于三（3）个客户订阅的三（3）个SAML SP企业应用程序）。

（IA）每个SAML SP演示应用程序都在Docker容器的不同“外部”端口上运行。

docker run -it --rm -p 2081:80 -p 2441:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2082:80 -p 2442:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest
docker run -it --rm -p 2083:80 -p 2443:443 --name="shibboleth-sp-1" example/shibboleth-sp:latest

（IB）使用HAProxy将Docker容器的不同“外部”端口映射到客户的不同子域，例如

2441 to  https://customer1.your-software.com/
2442 to  https://customer2.your-software.com/
2443 to  https://customer3.your-software.com/

（II）在另一台相同的物理机器/服务器（例如Ubuntu服务器）上运行三（3）个SAML IdP docker容器（为由三（3）个客户订阅的三（3）个企业应用程序提供SAML身份验证）。

出于演示目的，您可以将两（2）台物理计算机用于SAML IdP和SAML SP，并将本地DNS和端口配置用于不同的域名，例如，

10.10.40.10 customer1.your-software.com customer2.your-software.com customer3.your-software.com 

10.10.40.11 customer1.saml-idp.com customer2.saml-idp.com customer3.saml-idp.com

（II.A）每个SAML IdP在Docker容器的不同“外部”端口上运行。

docker run --rm -it ... -v $(pwd)/ext-conf:/opt/shibboleth-idp-ext-conf --link openldap:openldap -p 8441:8443 --name="shibboleth-idp-1" example/shibboleth-idp:latest $@

docker run --rm -it ... -p 8442:8443 --name="shibboleth-idp-2" example/shibboleth-idp:latest $@

docker run --rm -it ... -p 8443:8443 --name="shibboleth-idp-3" example/shibboleth-idp:latest $@

... means the missing docker parameters to be added (with reference to run.sh)

（II.B）使用HAProxy将Docker容器的不同“外部”端口映射到与客户的SAML SP应用程序相对应的SAML IdP的不同子域，例如

8441 to  https://customer1.saml-idp.com/
8442 to  https://customer2.saml-idp.com/
8443 to  https://customer3.saml-idp.com/

（III）在SAML SP（例如，https： //customer1.your-software.com/）和SAML IdP（例如，https： //customer1.saml-idp.com/）之间交换SAML元数据。

备注

您可以访问Salesforce SSO和Box SSO网站，以了解Salesforce和Box如何为他们的不同客户分配不同的子域，从而允许客户将其子域配置为客户自己的SAML IdP的不同SAML SP。

请注意，我们的零密码身份验证和授权系统是Box的技术合作伙伴。

后续问题2：

我应该使用该信息在我的应用上创建一个jwt，如果该jwt过期，我应该再次重定向到SAML吗？

答：

不需要。您不需要在企业应用程序上创建jwt。

相反，当SSO会话到期时，应将您的企业应用程序重定向到SAML IdP进行其他身份验证。

后续问题3：

有没有我可以用来测试实施情况的“免费” idp，您知道吗？

答：

Shibboleth SAML IdP是我可以用来测试实现的“免费” idp。

有两（2）个选项可利用Shibboleth SAML IdP测试您的SAML SP企业应用程序的实现。

（1）运行独立的Shibboleth SAML IdP

如何在GitHub存储库中使用Docker容器构建和运行Shibboleth SAML IdP和SP，可以让您在自己的测试平台上构建和运行独立的IdP Simulator。自己运行独立的SAML IdP模拟器可让您通过检查IdP和由您开发的SP的服务器日志来测试SP代码并调试SAML SP日志。

（2）利用在线Shibboleth SAML IdP

TestShib是Shibboleth社区构建和运行的在线Shibboleth IdP模拟器。TestShib网站演示

“ TestShib服务的最初创建者之一为每个人的利益构建了TestShib的替代产品。该站点称为SAMLTest（由Signet提供）*，您可以通过浏览到那些位置来了解有关它们的更多信息。”