1

openam SSO を使用してすべて認証される多数の Web サイトの保守を開始しました。ただし、ユーザーの 1 人が永続的な Cookie (DProPCookie) を設定すると、常に機能するとは限りません。

再現シナリオは次のとおりです。

  1. 永続的な Cookie を設定して、openam にログインします。
  2. ブラウザを再起動します (セッション Cookie をクリアするため)
  3. サイト A に移動すると、永続的な Cookie により、ユーザーは自動的にログインします
  4. サイト B に移動すると、ユーザーにログイン ページが表示されます (自動的にログインする必要があります)。

ステップ 3 の後、ブラウザから iPlanetDirectoryPro Cookie を削除すると、サイト B に正常にログインできます (永続的な Cookie を使用)。DProPCookie が設定されている場合にサイト A から生成された iPlanetDirectoryPro Cookie は、サイト B では機能しないようです。

サイト A と B のさまざまな順列を試してみましたが、いずれの場合もシナリオは同じであることに注意してください。

私は openam にまったく慣れていないので、これをデバッグする方法についてのヒントがあれば、または明らかにうまくいかないものがない場合はお知らせください。

前もって感謝します。

編集:

その後、DProPCookie を使用した認証時に返された iPlanetDirectoryPro Cookie が機能しないことを発見しました。したがって、クロスドメインとは何の関係もありません。

  1. 永続的な Cookie を設定して、openam にログインします。
  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);

   }
4

3 に答える 3

1

OpenAM で Persistent Cookie モードが変更されました ... DProCookie は実際には使用されなくなりました。

おそらく、「制限付きトークン モード」または「Cookie アンチ ハイジャック モード」を実行していて、CDCServlet が適切な認証アサーションを発行していない可能性があります。

于 2012-11-28T06:48:43.223 に答える
1

https://bugster.forgerock.org/jira/browse/OPENAM-1002に遭遇している可能性がありますか? また、Cookie ドメインに問題がある可能性もあります。サイト B が、DProPCookie が表示されない別のドメインにリダイレクトされている可能性があります。

于 2012-11-28T09:35:35.743 に答える
0

最終的に、問題は永続Cookieによって生成されたSSO Cookieに認証モジュールがないことであることがわかりました。したがって、認証レベルはInteger.MIN_VALUE;に設定されました。

私たちの状況では、少しハッキーな修正を行って、代わりにこれを0に強制しました。これにより、問題が修正されます。

正しいことは、永続的なCookieログイン用に個別の認証モジュールを用意するか、永続的なCookieによって生成されたSSOCookieに認証モジュールを保存することだと思います。

于 2012-12-13T12:59:08.207 に答える