我试图保存我们的服务用户不必拥有多个帐户/密码。 我在一个大型组织中，并且有一个组处理来自设施外（主要用于pipe理function）的用户的部分用户authentication。 他们存储一个安全的cookie来build立一个会话，并只通过HTTPS通过浏览器进行通信。 会话将通过以下方式到期：1）显式注销用户2）不活动3）浏览器closures
我的团队正在尝试编写一个Web应用程序，以帮助用户分析他们在我们工厂进行的（或正在进行的）数据。 我们需要确定一个用户是否是1）authentication2）该用户的一些标识符，所以我们可以为他们存储状态（他们正在做什么分析等）
所以，问题是你如何validation跨域（另一个应用程序的身份validation服务器生活在公共和私人之间的边界地区 – 我们将生活在公共区域）。
我们已经提出了一些情况，我想就什么是最佳实践提出build议，或者是否有我们没有考虑的问题。
我们从用validation服务器validation用户的情况开始。
1）authentication服务器在浏览器中为用户留下一个公共的cookie和主键。 如果这被认为是敏感的，他们encryption在他们的服务器上，我们有密钥在我们的服务器上解密。 当用户访问我们的网站时，我们检查这个公共cookie。 我们提取user_id，并使用一个公共的API来authentication服务器，以请求用户是否login。如果他们是，他们给我们一个回应：
response = {userid：我们可以将其映射到我们自己的用户ID。 如有必要，我们可以要求提供其他信息，例如电子邮件地址/显示名称（如果长时间运行的作业已完成，或者与其他人共享结果，请使用google_docs）。 account_is_active：确保帐户仍然有效session_is_active：他们的会话是否仍然处于活动状态？ 如果我们查询一个有效的用户，这将有一个副作用，我们将重置last_time_session_activated值，从而延长与authentication服务器的会话last_time_session_activated：让我们知道多less时间，他们离开ip_address_session_started_from：确保在我们的人网站来自相同的IP，因为他们开始会议在}
鉴于这种回应，我们要么接受他们的身份validation，并继续与我们的应用程序，或redirect到身份validation服务器的login页面（问题：如果我们给予encryption部分的响应（由我们签名）的页面redirect他们到，我们打开authentication服务器中的任何漏洞安全漏洞）？
我们发现这个缺陷是，如果用户访问evilsite.com，他们查看会话cookie并向authentication服务器的公共API发送一个查询，他们可以保持会话活着，如果我们的原始用户离开该机器没有注销，那么下一个用户将能够访问他们的会话（这之前是可能的，但会话永远存在使得这个更糟糕）。
2）authentication服务器将所有对我们域的请求redirect给我们，我们通过它们向用户发回响应。 从本质上讲，它们是一个代理。 这样做的好处是我们可以与authentication服务器握手，所以用户的电子邮件地址/名字是可信的，而且不必重新input
所以，如果用户试图去：authentication_site / mysite_page1，他们被redirect到mysite。
你会select哪一个，还是有更好的方法？ 目标是尽量减less“另一个密码/另一个用户名”的问题…
谢谢！！！！
这是非常抽象的，所以这将是一个抽象的答案。
这里有两个问题。 身份validation和授权，通常缩写为authn（身份validation）和authz（授权）。 身份validation正在validation用户是谁，他们是谁，授权允许他们根据他们是谁做的东西。 首先是AuthN，然后是AuthZ。
看到您是ServerFault的注册用户，您已经遇到了一种方法来处理多域AuthN与单个域AuthZ。 它被称为OpenID，旨在解决你所描述的问题。 用户使用OpenID提供者（例如google或yahoo）进行身份validation，并且依赖方（ServerFault）接受用户身份validation并根据此提供授权。 ServerFault不处理密码的业务。
这里的技巧是将authn和authz分开。 如果你能说服你的环境允许这样的事情，你的工作变得更容易。 你甚至可以使用OpenID，因为依赖方可以限制他们信任的提供者。
从问题的模糊性来看，我只能猜测需要什么技术。 我想看看可能与AD FS一起设置AD LDS数据库（概述链接）。 这将允许您使用LDAP进行授权和任意数量的身份validation方法（包括您可能已经使用的活动目录或Kerberos）。
显然这个答案是关注于一个Windows /微软开发堆栈 – 因为没有任何操作系统标签是想知道是否合适。
我的团队正在尝试编写一个Web应用程序，以帮助用户分析他们在我们工厂进行的（或正在进行的）数据
是吗？ 你的意思是你想审计所有的数据访问？ 或者你只是想分析使用？ 它们是完全不同的 – 前者必须与authentication紧密结合 – 但这是以很多处理为代价的。
你如何validation跨域
有很多文档描述了如何使用cookie来实现Web会话的SSO。
你提出的build议是让系统WIDE打开重播攻击，通过我的阅读，依靠所有的应用程序被提供相同的cookie（意味着应用程序都在相同的虚拟主机，或者你正在尝试使用第三方cookie – 这是一个非常糟糕的主意）。
如果用户访问evilsite.com，他们会看到会话cookie
所以你使用的是第三方的cookies–这不仅是一个巨大的安全漏洞，它不是所有浏览器都可以移植的，即使是特定的浏览器也会因configuration而异。
（如果您尝试分析/审核使用情况，您为什么要尝试创buildSSO系统？）
会话中使用的代理标识符（通常是会话cookie）必须是一个随机值 – 使用可逆encryption有一些原因，但是很容易弄错，从而暴露您的密钥 – 然后您的安全性被烘烤。 为了避免注入问题，必须在会话被authentication时为每个应用程序独立生成（重新），并在会话终止时被覆盖 – 这意味着当会话是（re）时，您的应用程序需要回发到某个中央存储库）生成（NB我正在谈论服务器到服务器的消息在这里 – 而不是通过客户端）。 身份validation服务器应通过url查询参数以及操作的序列号（例如，在redirect中使用salted哈希来validation信息 – 将salt作为共享密钥）将身份validation状态发送到应用程序。 再次，应用程序应回发（服务器到服务器），用户已经authentication和序列号（以提供额外的保护，以防止重播），并检查authentication服务器是否满意，然后释放新的会话标识符到客户端。
该cookie应该只有HTTP – 而且优先被标记为仅SSL。 它应该被限制在不仅规范的领域，而且应用程序的path。