LTPA 如何作为 SSO（单点登录）机制工作
How does LTPA works as a SSO(single sign on) mechanism
我从一篇不错的博客文章中了解了 SSO 原理的基本知识
访问 https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/#
而且我认为要实现 SSO，我们使用中央域（例如 LDAP 或其他身份验证服务器）进行身份验证，它可以生成令牌并存储为 cookie 或仅存储在浏览器的存储中。
下次我们访问另一个域中的应用程序时，它会重定向到 Auth Server 并可以使用我们之前存储的令牌，然后我们可以为我们要访问的域获取一个包含此令牌的新 cookie。
这样一来，我认为SSO就是使用中央Auth Server作为第三台托管服务器或者我们可以称之为委托服务器为不同的域生成不同的cookie，这样我们就解决了单一来源政策(cookie只能由其创建者访问，不能跨域)。
如果那是 SSO 的工作方式，我对 IBM LTPA 感到困惑。我正在使用 WAS，从指南中可以看出，如果我想实现 SSO，我需要从第一台服务器获取一个 LTPA 密钥，并将其复制到我想要实现 SSO 功能的每个服务器。 LTPA 密钥包括 public 密钥和用于解密由 WAS 生成的 LTPA 令牌的私钥。
因此，如果我使用 LDAP 作为 Auth 服务器，首先我在域 1 上访问我的应用程序，我的请求将被重定向到登录页面，并在 LDAP 中进行身份验证后（这里我认为 LDAP 不会生成token), WAS 会生成一个带有 LTPA token 的 cookie，但是当我们想要访问域 2 中的应用程序时（这个域中的 WAS 已经获得了 LTPA 密钥），我们的 LTPA token 可以被解密并且我们得到了我们的 userId（或者一些字段可以识别用户），然后我们再次去我们的 LDAP Auth 服务器验证这个 userId...
我不知道我的理解对不对，但我认为这不能称为"SSO"。因为，首先，我们拿到的token是WAS生成的，不是LDAP，所以拿到的只是一个userId，解密这个token的时候，需要在LDAP中再次验证这个用户。其次，我们用来使 SSO 工作的方法是传递一个带有 LTPA 令牌的 cookie，但是 cookie 不能跨域发送……所以如果域 1 和域 2 不是同一个领域，这就不可能发生……因为我们无法在域 2 中获取 cookie...
我快气死了...
谁能告诉我 LTPA 如何通过使用 LTPA 密钥准确地用作 SSO 机制....
非常感谢！
LTPA 是一种将身份验证从 WebSphere（或后端服务器）转移到 SSO 服务器的机制 - 让我们谈谈 IBM ISAM (WebSeal)
用户--->ISAM SSO (WebSeal)- LTPA 在这里---->后端服务器 WAS)
后台WAS服务器一般不做任何认证。
用户向 SSO 服务器进行身份验证，SSO 服务器将加密的 LTPA 令牌发送到包含用户用户名（通常只有用户名、组成员身份，但从不包含密码）的后端服务器。
后端服务器解密 LTPA 并作为 LTPA 并信任它。然后后端应用程序服务器 (WAS) 将此身份验证详细信息传递给应用程序。
请查看将 IBM Cognos（WAS 上的应用程序）置于 SSO 服务器之后的示例。
LTPA 是部署在 WebSphere（以及其他一些 IBM 产品，例如 Domino）上的不同应用程序之间的单点登录。它的基本功能是在一个单元中工作，在各种服务器中的各种应用程序之间工作，或者在单元之间（交换密钥的地方）之间更复杂的场景中工作。
正如您已经发现的那样，它不是跨 DNS 域的，因此它仅限于单个公司（尽管支持子域）。
如果您有远程 EJB，它还支持通过 IIOP 向下游传播凭证。
如果您正在寻找跨域 SSO 机制，WebSphere 支持 SAML 和 Open ID Connect。
我从一篇不错的博客文章中了解了 SSO 原理的基本知识 访问 https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/#
而且我认为要实现 SSO，我们使用中央域（例如 LDAP 或其他身份验证服务器）进行身份验证，它可以生成令牌并存储为 cookie 或仅存储在浏览器的存储中。
下次我们访问另一个域中的应用程序时，它会重定向到 Auth Server 并可以使用我们之前存储的令牌，然后我们可以为我们要访问的域获取一个包含此令牌的新 cookie。
这样一来，我认为SSO就是使用中央Auth Server作为第三台托管服务器或者我们可以称之为委托服务器为不同的域生成不同的cookie，这样我们就解决了单一来源政策(cookie只能由其创建者访问，不能跨域)。
如果那是 SSO 的工作方式，我对 IBM LTPA 感到困惑。我正在使用 WAS，从指南中可以看出，如果我想实现 SSO，我需要从第一台服务器获取一个 LTPA 密钥，并将其复制到我想要实现 SSO 功能的每个服务器。 LTPA 密钥包括 public 密钥和用于解密由 WAS 生成的 LTPA 令牌的私钥。
因此，如果我使用 LDAP 作为 Auth 服务器，首先我在域 1 上访问我的应用程序，我的请求将被重定向到登录页面，并在 LDAP 中进行身份验证后（这里我认为 LDAP 不会生成token), WAS 会生成一个带有 LTPA token 的 cookie，但是当我们想要访问域 2 中的应用程序时（这个域中的 WAS 已经获得了 LTPA 密钥），我们的 LTPA token 可以被解密并且我们得到了我们的 userId（或者一些字段可以识别用户），然后我们再次去我们的 LDAP Auth 服务器验证这个 userId...
我不知道我的理解对不对，但我认为这不能称为"SSO"。因为，首先，我们拿到的token是WAS生成的，不是LDAP，所以拿到的只是一个userId，解密这个token的时候，需要在LDAP中再次验证这个用户。其次，我们用来使 SSO 工作的方法是传递一个带有 LTPA 令牌的 cookie，但是 cookie 不能跨域发送……所以如果域 1 和域 2 不是同一个领域，这就不可能发生……因为我们无法在域 2 中获取 cookie...
我快气死了...
谁能告诉我 LTPA 如何通过使用 LTPA 密钥准确地用作 SSO 机制....
非常感谢！
LTPA 是一种将身份验证从 WebSphere（或后端服务器）转移到 SSO 服务器的机制 - 让我们谈谈 IBM ISAM (WebSeal)
用户--->ISAM SSO (WebSeal)- LTPA 在这里---->后端服务器 WAS)
后台WAS服务器一般不做任何认证。 用户向 SSO 服务器进行身份验证，SSO 服务器将加密的 LTPA 令牌发送到包含用户用户名（通常只有用户名、组成员身份，但从不包含密码）的后端服务器。 后端服务器解密 LTPA 并作为 LTPA 并信任它。然后后端应用程序服务器 (WAS) 将此身份验证详细信息传递给应用程序。
请查看将 IBM Cognos（WAS 上的应用程序）置于 SSO 服务器之后的示例。
LTPA 是部署在 WebSphere（以及其他一些 IBM 产品，例如 Domino）上的不同应用程序之间的单点登录。它的基本功能是在一个单元中工作，在各种服务器中的各种应用程序之间工作，或者在单元之间（交换密钥的地方）之间更复杂的场景中工作。 正如您已经发现的那样，它不是跨 DNS 域的，因此它仅限于单个公司（尽管支持子域）。 如果您有远程 EJB，它还支持通过 IIOP 向下游传播凭证。
如果您正在寻找跨域 SSO 机制，WebSphere 支持 SAML 和 Open ID Connect。