各認証方法では、ユーザーは認証に成功するか失敗します。成功または失敗の決定後、各方法では次の手順を実行します。手順 1 〜 3 は認証が成功した場合に実行され、手順 4 は成功した認証と失敗した認証の両方で実行されます。
Access Manager によって、認証されたユーザーが Directory Server データストアに定義されているかどうか、またプロファイルが有効であるかどうかが確認されます。
コア認証モジュールの「ユーザープロファイル」属性は、「必須」、「動的」、「ユーザーエイリアスを使用して動的に」、または「無視」として定義できます。認証に成功すると、Access Manager によって、認証されたユーザーが Directory Server データストアに定義されているかどうかが確認され、「ユーザープロファイル」の値が「必須」である場合は、プロファイルが有効かどうかが確認されます。これはデフォルトの場合です。「ユーザープロファイル」が動的な設定である場合、認証サービスはユーザープロファイルを Directory Server のデータストアに作成します。「ユーザープロファイル」が「無視」に設定されている場合は、ユーザーの検証は行われません。
認証ポストプロセス SPI が実行されます。
コア認証モジュールには、値として認証ポストプロセスクラス名を含む「認証ポストプロセスクラス」属性が含まれています。AMPostAuthProcessInterface は、ポストプロセスインタフェースです。このインタフェースは、認証の成功または失敗時、またはログアウト時に実行できます。
セッショントークンで次のプロパティーが追加または更新され、ユーザーのセッションがアクティブになります。
realm: これは、ユーザーが所属するレルムの DN です。
Principal: ユーザーの DN です。
Principals: ユーザーが認証を受けた名前のリストです。このプロパティーは、パイプで区切られたリストとして定義された複数の値を持つことができます。
UserId: モジュールが返すユーザーの DN であるか、LDAP またはメンバーシップ以外のモジュールの場合はユーザー名です。すべての Principal は、同じユーザーにマッピングされる必要があります。UserId は、すべての Principal がマッピングされるユーザー DN です。
このプロパティーは、DN 以外の値になることがあります。
UserToken: ユーザー名です。すべての Principal は、同じユーザーにマッピングされる必要があります。UserToken は、すべての Principal がマッピングされるユーザー名です。
Host: クライアント用のホスト名または IP アドレスです。
authLevel: ユーザーが認証を受けた最高のレベルです。
AuthType: ユーザーが認証を受けた認証モジュールの、パイプで区切られたリストです (例、module1|module2|module3)。
clientType: クライアントブラウザのデバイスタイプです。
Locale: クライアントのロケールです。
CharSet: クライアント用に定めらた文字セットです。
Role: ロールに基づく認証にのみ適用可能であり、ユーザーが属すロールです。
Service: サービスに基づく認証にのみ適用可能であり、ユーザーが属すサービスです。
Access Manager は、成功または失敗した認証のあとにユーザーをリダイレクトする場所についての情報を検索します。
URL のリダイレクトは、Access Manager のページまたは URL のどちらかにすることができます。リダイレクトは、Access Manager が認証方法に基づいて、また認証が成功したか失敗したかによってリダイレクトを検索する優先順位のもとに行われます。この順序については、次の認証方法についての節の、URL のリダイレクトの部分で詳しく説明します。
認証設定サービスでは、成功または失敗した認証に対する URL のリダイレクトを割り当てることができます。その URL 自体は、認証設定サービスの「ログイン成功 URL」および「ログイン失敗 URL」属性で定義します。URL のリダイレクトを有効にするために、ロール、レルム、またはユーザー用に設定するように、認証設定サービスをレルムに追加し、利用可能にする必要があります。認証設定サービスの追加時は、LDAP で必須、というように認証モジュールを追加するようにしてください。