【问题标题】:SSO cookie not working when using persitent cookie in openam/opensso在 openam/opensso 中使用持久性 cookie 时,SSO cookie 不起作用
【发布时间】:2012-11-27 09:20:20
【问题描述】:

我已经开始维护一些网站,这些网站都使用 openam SSO 进行了身份验证。但是,当我们的一位用户设置持久性 cookie (DProPCookie) 时,它并不总是有效。

重现场景是:

  1. 登录到 openam,设置持久 cookie
  2. 重启浏览器(清除会话 cookie)
  3. 转到站点 A,由于持久性 cookie,用户自动登录
  4. 转到站点 B,用户会看到一个登录页面(他们应该会自动登录)。

在第 3 步之后,如果我从浏览器中删除 iPlanetDirectoryPro cookie,我可以正常登录站点 B(使用持久性 cookie)。设置 DProPCookie 时从站点 A 生成的 iPlanetDirectoryPro cookie 似乎在站点 B 上不起作用。

请注意,我尝试了站点 A 和 B 的各种排列,并且每种情况下的场景都是相同的。

我对 openam 很陌生,所以任何关于如何调试它的提示都会很棒,或者如果我遗漏了一些明显出错的地方,请告诉我。

提前致谢。

编辑:

我随后发现使用 DProPCookie 进行身份验证时返回的 iPlanetDirectoryPro cookie 不起作用。所以与跨域无关。

  1. 登录到 openam,设置持久 cookie
  2. 重启浏览器(清除会话 cookie)
  3. 转到站点 A,由于持久性 cookie,用户自动登录
  4. 删除除 iPlanetDirectoryPro cookie 之外的所有 cookie
  5. 刷新页面 - 要求登录

如果我重复测试但使用正常登录生成的 iPlanetDirectoryPro cookie,那么当我刷新页面时,我会自动获得身份验证。 (我已更改问题的标题以反映这一点)。

进一步编辑:

启动调试 - 我在日志中看到此异常:

IdName is :null
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
orgName is :xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity() from IdUtils Name: null Org: xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity: Got IdRepoException while getting Identity from IdUtils: Illegal universal identifier null.
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
isLockedOut:Exception :
java.lang.NullPointerException
        at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:585)
        at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:296)
        at com.sun.identity.authentication.service.AuthD.getIdentity(AuthD.java:1453)
        at com.sun.identity.authentication.service.AMAccountLockout.isMemoryLockout(AMAccountLockout.java:297)
        at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:281)
        at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:264)
        at com.sun.identity.authentication.service.AMLoginContext.processPCookieMode(AMLoginContext.java:1919)
        at com.sun.identity.authentication.service.AMLoginContext.processIndexType(AMLoginContext.java:1846)

快速扫描 openam 代码 - 我们似乎没有在 AMAccountLockout.java:264 中获得用户名:

   public boolean isLockedOut() {

       // has this user been locked out.

       String userDN = loginState.getUserToken();

       return isLockedOut(userDN);

   }

【问题讨论】:

  • 对我来说似乎是一个错误,可能持久性 cookie 在使用帐户锁定功能时也不能很好地工作。

标签: authentication cookies persistence openam opensso


【解决方案1】:

OpenAM 中的 Persistent Cookie 模式已更改...实际上不再使用 DProCookie。

您可能正在运行“受限令牌模式”又名“cookie 反劫持模式”,而 CDCServlet 没有发出正确的身份验证断言

【讨论】:

  • 我使用的是 openam 版本 9.5.3 - 我相信持久性 iPlanetDirectoryPro cookie 在 10.0.0 中。另外,我不相信我们在受限令牌模式下运行。似乎正在发生的只是当客户端使用持久性 DProPCookie 进行身份验证时返回的 iPlanetDirectoryPro cookie 实际上无效。
【解决方案2】:

可能是您遇到了https://bugster.forgerock.org/jira/browse/OPENAM-1002 吗? 也可能是您的 cookie 域有问题,也许站点 B 重定向到 DProPCookie 不可见的其他域?

【讨论】:

  • 我首先想到的是域的问题(因为它首先是在位于不同域的两个站点之间发现的)。但是,同一域上的两个站点也会发生这种情况。我们的系统似乎也只使用一个领域。所以我们不能碰到那个错误。还是谢谢!
【解决方案3】:

最终我们发现问题在于持久 cookie 生成的 SSO cookie 没有身份验证模块 - 因此身份验证级别设置为 Integer.MIN_VALUE;。

在我们的情况下,我们做了一个稍微有点骇人听闻的修复,将其强制为 0,从而解决了问题。

我认为正确的做法是为持久 cookie 登录设置单独的身份验证模块,或者将身份验证模块存储在由持久 cookie 生成的 SSO cookie 中。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-19
    • 1970-01-01
    • 1970-01-01
    • 2016-04-24
    • 2013-03-06
    • 1970-01-01
    相关资源
    最近更新 更多