实施 SAML SSO
implement SAML SSO
我正在构建 SaaS，我的想法是让我的客户使用他们自己的身份验证系统登录我的应用程序。
执行此操作的最佳方法是什么？我将有多个客户，每个客户都可以配置 SAML SSO。
我也很关心如何初始加载用户。
通常公司会提供用户电子邮件列表，我只是将它们批量插入数据库，否则在他们开始登录之前该帐户将没有任何用户？
当用户不再是公司的一部分时，如何管理场景？公司提供要停用的用户列表？
这更像是一个概念性问题，因为现在如果你想构建企业软件，你必须与他们的身份验证系统集成。
Scim 是用于将用户从身份提供商提供给您的数据库的协议。
Scimgateway 是一种实现 https://github.com/jelhub/scimgateway
您需要 SAML IDP 作为 SaaS 的一部分。
然后你给其他方你的元数据，他们给你他们的，这样你就可以整合。
您可能希望使用 Identity aaS，例如Azure AD、Auth0 等
在用户方面，您允许其他 IDP 进行身份验证。这些其他 IDP 控制其用户的入职。你不用担心。他们使用联盟，而联盟意味着他们使用他们的凭据来访问您的系统。
如果您需要 "standalone" 个用户，您需要注册页面、密码重置页面等。这不是 SAML 的一部分。
这些设施是由云IDP提供的，如上。他们的登录页面通常提供注册、登录和密码重置。
我有为拥有 15-20,000 用户的组织跨数十个应用程序设置 SSO 的经验。以下是一些可能相关的经验提示：
如果您没有真正需要创建帐户，请不要。相反，依靠有效的 IDP 响应作为他们已通过身份验证的证据。如果您需要授权，也许您可以依靠 IDP 来管理它。例如，AWS 查找多值属性 https://aws.amazon.com/SAML/Attributes/Role 以确定 IDP 断言用户具有的角色。如果没有角色，则用户已通过身份验证但不能执行任何操作。
SSO的前提是IDP在用户离开时不再对用户进行鉴权，所以也许你不需要在用户离开时取消配置。如果您需要删除 SaaS 中的陈旧数据（例如，您想显示所有组织用户但不想包括那些离开的用户），也许只是过滤掉在一段时间内未登录 SaaS 的用户.
如果您确实需要一种方法来取消配置帐户（例如，因为您允许绕过 SSO 的用户链接 API 密钥），您可以首先授权组织管理员执行手动。我相信 Slack 使用该模型，即使对于 SSO 管理的用户也是如此。
如果您想允许 SP 发起的登录（AWS 不允许，但 gmail 允许），请使用类似 google 的流程，用户首先只输入他们的电子邮件地址（或像 New Relic 这样的空密码）。该电子邮件将允许您查找组织的 IDP 详细信息并将用户重定向到组织自己的 IDP。
SAML 规范已有将近 15 年的历史，因此除了 SAML 之外，请考虑支持 OAuth/OIDC。这将允许组织依赖 GitHub、LinkedIn 等作为他们的 IDP，而不是设置自己的 IDP（如果您决定不需要 IDP 管理的角色）。
从上线开始，为 AD FS、Auth0、Google 应用程序等一些流行的 IDP 提供支持，以最大程度地减少让您的 SaaS 被企业采用的摩擦。
问题 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 实施了并行解决方案，它是 Zero-Password Authentication and Authorization System 的一部分。
问题2:
我也很关心如何初始加载用户。通常公司会提供用户电子邮件列表，我只是将它们批量插入数据库，否则在他们开始登录之前该帐户将没有任何用户？
回答:
由于 SAML SP 和 SAML IdP（即您客户自己的身份验证系统）通过元数据交换建立了相互信任，因此 SAML SP（配备您的企业软件）应该信任从 SAML IdP（即，您客户自己的身份验证系统）。
(1) 在用户开始登录之前，该帐户将没有任何用户。
(2) 当新用户最初登录到您的基于云的企业应用程序时，在无法从数据库中找到用户信息后，您的企业网络应用程序会将新用户信息插入到数据库中。
问题3:
当用户不再是公司的一部分时，如何管理场景？公司提供要停用的用户列表？
回答:
(1) 当用户不再属于公司时，您的客户将从他们的身份验证系统中停用该用户。然后用户无法登录到您的基于云的企业 Web 应用程序
(I) 当用户访问基于云的企业 Web 应用程序时，用户将被重定向到您客户自己的身份验证系统（即 SAML IdP）。
(II) 已停用的用户将不会通过您客户自己的身份验证系统进行身份验证。
(III) 停用的用户将不会被重定向回您的基于云的企业 Web 应用程序，SAML assertion/response 携带用户信息。因此，停用的用户将无法登录到您的基于云的企业 Web 应用程序。
(2) 您的企业 Web 应用程序为每个客户的 IT 主管分配他们自己的组织子域的管理权限，例如 customer1.your-software.com.
登录到您的企业 Web 应用程序后，IT 负责人可以remove/delete/deactivate他们组织的任何用户，例如您企业 Web 应用程序数据库中的 customer1。
官方 Okta 网站 What is 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，该服务绑定到企业应用程序每个客户的子域。
(2) How to build and run Shibboleth SAML IdP and SP using Docker container 在 GitHub 存储库中提供了使用 Shibboleth SAML IdP 和 OpenLDAP 以及 SAML SP 网络应用程序（可以被视为简化的企业应用程序，允许付费用户访问受保护的 Web 资源）。
- Shibboleth SAML IdP 负责身份联合。
- OpenLDAP 负责身份认证。
您可以使用上面的 GitHub 存储库来模拟您的 SAML SP 企业应用程序与多个客户及其相应的 SAML IdP。
(I) 运行 三 (3) 个 SAML SP 演示应用程序 docker 容器（对应于三 (3) 个客户订阅的三 (3) 个 SAML SP 企业应用程序）物理 machine/server（例如 Ubuntu 服务器）。
(I.A)每个 SAML SP 演示应用程序 运行s 在 Docker 容器的不同 "external" 端口上。
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
(I.B) 使用 HAProxy 将 Docker 容器的不同 "external" 端口映射到您客户的不同子域，例如
2441 to https://customer1.your-software.com/
2442 to https://customer2.your-software.com/
2443 to https://customer3.your-software.com/
(II) 运行 三 (3) 个 SAML IdP docker 容器（为三 (3) 个客户订阅的三 (3) 个企业应用程序提供 SAML 身份验证）在另一个相同的物理 machine/server（例如Ubuntu服务器）。
出于演示目的，您可以将两 (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) Docker 容器的不同 "external" 端口上的每个 SAML IdP 运行s。
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 容器的不同 "external" 端口映射到与客户的 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 之间交换 SAML 元数据（例如，https://customer1.your-software.com/) and SAML IdP (e.g., https://customer1.saml-idp.com/）。
备注
您可以查看 Salesforce SSO and Box SSO 网站以了解 Salesforce 和 Box 如何为不同的客户分配不同的子域，从而允许客户将其子域配置为客户自己的 SAML IdP 的不同 SAML SP。
请注意，我们的 Zero-Password Authentication and Authorization System 是 Box 的技术合作伙伴。
后续问题 #2：
我是否应该使用该信息在我的应用程序上创建一个 jwt，如果该 jwt 过期我应该再次重定向到 SAML？
回答:
没有。您不需要在企业应用程序上创建 jwt。
相反，当 SSO 会话过期时，您的企业应用程序应重定向到 SAML IdP 以进行另一次身份验证。
后续问题 #3：
是否有 "free" idp 我可以用来测试实施你知道吗？
回答:
Shibboleth SAML IdP 是一个 "free" idp，我可以用它来测试实现。
有两 (2) 个选项可用于利用 Shibboleth SAML IdP 来测试 SAML SP 企业应用程序的实施。
(1) 运行宁独立口令 SAML IdP
How to build and run Shibboleth SAML IdP and SP using Docker container GitHub 存储库允许您在自己的测试平台上构建并 运行 独立的 IdP 模拟器。 运行您自己安装一个独立的 SAML IdP 模拟器允许您通过检查您开发的 IdP 和您的 SP 的服务器日志来测试您的 SP 代码和调试您的 SAML SP 日志。
(2) 利用在线 Shibboleth SAML IdP
TestShib 是在线 Shibboleth IdP 模拟器，由 Shibboleth 社区构建 运行。
TestShib网站演示
"One of the original creators of the TestShib service has built an alternative to TestShib for everyone's benefit. The site is called SAMLTest (offered by Signet)* and you can learn more about them by browsing over to those locations."
我正在构建 SaaS，我的想法是让我的客户使用他们自己的身份验证系统登录我的应用程序。
执行此操作的最佳方法是什么？我将有多个客户，每个客户都可以配置 SAML SSO。
我也很关心如何初始加载用户。 通常公司会提供用户电子邮件列表，我只是将它们批量插入数据库，否则在他们开始登录之前该帐户将没有任何用户？
当用户不再是公司的一部分时，如何管理场景？公司提供要停用的用户列表？
这更像是一个概念性问题，因为现在如果你想构建企业软件，你必须与他们的身份验证系统集成。
Scim 是用于将用户从身份提供商提供给您的数据库的协议。
Scimgateway 是一种实现 https://github.com/jelhub/scimgateway
您需要 SAML IDP 作为 SaaS 的一部分。
然后你给其他方你的元数据，他们给你他们的，这样你就可以整合。
您可能希望使用 Identity aaS，例如Azure AD、Auth0 等
在用户方面，您允许其他 IDP 进行身份验证。这些其他 IDP 控制其用户的入职。你不用担心。他们使用联盟，而联盟意味着他们使用他们的凭据来访问您的系统。
如果您需要 "standalone" 个用户，您需要注册页面、密码重置页面等。这不是 SAML 的一部分。
这些设施是由云IDP提供的，如上。他们的登录页面通常提供注册、登录和密码重置。
我有为拥有 15-20,000 用户的组织跨数十个应用程序设置 SSO 的经验。以下是一些可能相关的经验提示：
如果您没有真正需要创建帐户，请不要。相反，依靠有效的 IDP 响应作为他们已通过身份验证的证据。如果您需要授权，也许您可以依靠 IDP 来管理它。例如，AWS 查找多值属性
https://aws.amazon.com/SAML/Attributes/Role以确定 IDP 断言用户具有的角色。如果没有角色，则用户已通过身份验证但不能执行任何操作。SSO的前提是IDP在用户离开时不再对用户进行鉴权，所以也许你不需要在用户离开时取消配置。如果您需要删除 SaaS 中的陈旧数据（例如，您想显示所有组织用户但不想包括那些离开的用户），也许只是过滤掉在一段时间内未登录 SaaS 的用户.
如果您确实需要一种方法来取消配置帐户（例如，因为您允许绕过 SSO 的用户链接 API 密钥），您可以首先授权组织管理员执行手动。我相信 Slack 使用该模型，即使对于 SSO 管理的用户也是如此。
如果您想允许 SP 发起的登录（AWS 不允许，但 gmail 允许），请使用类似 google 的流程，用户首先只输入他们的电子邮件地址（或像 New Relic 这样的空密码）。该电子邮件将允许您查找组织的 IDP 详细信息并将用户重定向到组织自己的 IDP。
SAML 规范已有将近 15 年的历史，因此除了 SAML 之外，请考虑支持 OAuth/OIDC。这将允许组织依赖 GitHub、LinkedIn 等作为他们的 IDP，而不是设置自己的 IDP（如果您决定不需要 IDP 管理的角色）。
从上线开始，为 AD FS、Auth0、Google 应用程序等一些流行的 IDP 提供支持，以最大程度地减少让您的 SaaS 被企业采用的摩擦。
问题 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 实施了并行解决方案，它是 Zero-Password Authentication and Authorization System 的一部分。
问题2:
我也很关心如何初始加载用户。通常公司会提供用户电子邮件列表，我只是将它们批量插入数据库，否则在他们开始登录之前该帐户将没有任何用户？
回答:
由于 SAML SP 和 SAML IdP（即您客户自己的身份验证系统）通过元数据交换建立了相互信任，因此 SAML SP（配备您的企业软件）应该信任从 SAML IdP（即，您客户自己的身份验证系统）。
(1) 在用户开始登录之前，该帐户将没有任何用户。
(2) 当新用户最初登录到您的基于云的企业应用程序时，在无法从数据库中找到用户信息后，您的企业网络应用程序会将新用户信息插入到数据库中。
问题3:
当用户不再是公司的一部分时，如何管理场景？公司提供要停用的用户列表？
回答:
(1) 当用户不再属于公司时，您的客户将从他们的身份验证系统中停用该用户。然后用户无法登录到您的基于云的企业 Web 应用程序
(I) 当用户访问基于云的企业 Web 应用程序时，用户将被重定向到您客户自己的身份验证系统（即 SAML IdP）。
(II) 已停用的用户将不会通过您客户自己的身份验证系统进行身份验证。
(III) 停用的用户将不会被重定向回您的基于云的企业 Web 应用程序，SAML assertion/response 携带用户信息。因此，停用的用户将无法登录到您的基于云的企业 Web 应用程序。
(2) 您的企业 Web 应用程序为每个客户的 IT 主管分配他们自己的组织子域的管理权限，例如 customer1.your-software.com.
登录到您的企业 Web 应用程序后，IT 负责人可以remove/delete/deactivate他们组织的任何用户，例如您企业 Web 应用程序数据库中的 customer1。
官方 Okta 网站 What is 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，该服务绑定到企业应用程序每个客户的子域。
(2) How to build and run Shibboleth SAML IdP and SP using Docker container 在 GitHub 存储库中提供了使用 Shibboleth SAML IdP 和 OpenLDAP 以及 SAML SP 网络应用程序（可以被视为简化的企业应用程序，允许付费用户访问受保护的 Web 资源）。
- Shibboleth SAML IdP 负责身份联合。
- OpenLDAP 负责身份认证。
您可以使用上面的 GitHub 存储库来模拟您的 SAML SP 企业应用程序与多个客户及其相应的 SAML IdP。
(I) 运行 三 (3) 个 SAML SP 演示应用程序 docker 容器（对应于三 (3) 个客户订阅的三 (3) 个 SAML SP 企业应用程序）物理 machine/server（例如 Ubuntu 服务器）。
(I.A)每个 SAML SP 演示应用程序 运行s 在 Docker 容器的不同 "external" 端口上。
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
(I.B) 使用 HAProxy 将 Docker 容器的不同 "external" 端口映射到您客户的不同子域，例如
2441 to https://customer1.your-software.com/
2442 to https://customer2.your-software.com/
2443 to https://customer3.your-software.com/
(II) 运行 三 (3) 个 SAML IdP docker 容器（为三 (3) 个客户订阅的三 (3) 个企业应用程序提供 SAML 身份验证）在另一个相同的物理 machine/server（例如Ubuntu服务器）。
出于演示目的，您可以将两 (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) Docker 容器的不同 "external" 端口上的每个 SAML IdP 运行s。
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 容器的不同 "external" 端口映射到与客户的 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 之间交换 SAML 元数据（例如，https://customer1.your-software.com/) and SAML IdP (e.g., https://customer1.saml-idp.com/）。
备注
您可以查看 Salesforce SSO and Box SSO 网站以了解 Salesforce 和 Box 如何为不同的客户分配不同的子域，从而允许客户将其子域配置为客户自己的 SAML IdP 的不同 SAML SP。
请注意，我们的 Zero-Password Authentication and Authorization System 是 Box 的技术合作伙伴。
后续问题 #2：
我是否应该使用该信息在我的应用程序上创建一个 jwt，如果该 jwt 过期我应该再次重定向到 SAML？
回答:
没有。您不需要在企业应用程序上创建 jwt。
相反，当 SSO 会话过期时，您的企业应用程序应重定向到 SAML IdP 以进行另一次身份验证。
后续问题 #3：
是否有 "free" idp 我可以用来测试实施你知道吗？
回答:
Shibboleth SAML IdP 是一个 "free" idp，我可以用它来测试实现。
有两 (2) 个选项可用于利用 Shibboleth SAML IdP 来测试 SAML SP 企业应用程序的实施。
(1) 运行宁独立口令 SAML IdP
How to build and run Shibboleth SAML IdP and SP using Docker container GitHub 存储库允许您在自己的测试平台上构建并 运行 独立的 IdP 模拟器。 运行您自己安装一个独立的 SAML IdP 模拟器允许您通过检查您开发的 IdP 和您的 SP 的服务器日志来测试您的 SP 代码和调试您的 SAML SP 日志。
(2) 利用在线 Shibboleth SAML IdP
TestShib 是在线 Shibboleth IdP 模拟器，由 Shibboleth 社区构建 运行。 TestShib网站演示
"One of the original creators of the TestShib service has built an alternative to TestShib for everyone's benefit. The site is called SAMLTest (offered by Signet)* and you can learn more about them by browsing over to those locations."