3

ユーザー名とパスワードを要求することなく、自動認証に Cookie を使用する JSF Web アプリケーションがあります。ユーザー名とランダムな UUID を持つ Cookie を使用しWebFilter、リダイレクトに a を使用します。

クライアント側に Cookie がない場合、認証はHttpServletRequest #login(String username, String password)によって行われます。舞台裏では、このアプローチは JAAS 認証を使用し、LDAP背後でサーバーを使用します。

私の問題は、アプリケーションがユーザー ID と UUID を保持する Cookie を介してユーザーを認識するときに発生します。この状況では、

  1. アプリケーションはパスワードを知らないため、このメソッドHttpServletRequest #login(String username, String password)は使用できません。
  2. JNDI を介して LDAP サーバーにパスワードを要求する必要がありますか? これは一見不可能に思えます
  3. または、パスワードをデータベースに保存することもできます。しかし、これは情報の重複を意味し、私はそれが好きではありません。
  4. セッションに属性「ロール」を設定するだけの人を見たことがありますが、これは JAAS ログインと同等ではないようです。「同等」とはisUserInRole()getUserPrincipal()メソッドを使用できることを意味します。

問題は、この場合、ユーザーをどのようにログインさせるべきかということです。質問がより明確になったことを願っています。

編集

コードが話せるようにするために、Managed Bean の簡略化されたバージョンを追加します。

@ManagedBean
@SessionScoped 
public class loginBean() {
    private String username = null;
    private String password = null;
    private UUID uuid = null;
    private boolean rememberMe = false;

    public void doLogin() {
        checkCookies();   // this method sets the property values after checking if 
                          // username & uuid match the ones saved previously
        if (username != null && uuid != null && rememberMe) {
            // authenticate automatically. Here I don't know how to proceed, because 
            // I don't have the password, unless I have saved it in the application's db,
            // duplicating it because it's already in LDAP server.
        } else {
            httpServletRequest.login(username, password);  // this uses LDAP behind JAAS
            createCookies();  // this method also saves username & uuid in the app's db
        }
    }
4

2 に答える 2

3

カスタムの方法で実際のコンテナ ログインを行うには(この場合は、パスワードの代わりに Cookie と UUID を使用)、独自のログイン モジュールを作成する必要があります。

このための Java EE の専用 API は JASPI/JASPIC です (人々は名前にまったく同意できず、たとえば Google クエリを複雑にします)。

ログインモジュールは完全に制御されており、LDAP サーバーで認証する必要はありません (アプリがローカルで 100% 確実に Cookie が有効であることを確認できる場合)。おそらく、ユーザーを承認する必要があります (ユーザーが持っているロール/グループについて LDAP サーバーに問い合わせてください)。

JASPI/JASPIC の代わりに、サーバーが使用している独自のログイン モジュール メカニズムを確認することもできます。

于 2012-08-13T09:08:04.697 に答える
1

この場合に LDAP エントリを使用することは、ディレクトリ サーバーがアプリケーションによって提供される情報を使用して接続を認証するように要求することと同じです。LDAP に関して、認証とは、既存の LDAPセッション(ディレクトリ サーバーへの接続) の認証状態が BIND 要求の成功によって変更されたことを意味します。

Web アプリケーションは、認証されるユーザーに適切な情報を要求し、この情報を BIND 要求としてディレクトリ サーバーに提示する必要があります。必要な情報は、Web アプリケーション (LDAP クライアント) で使用される認証方法によって異なります。

  • 単純な BIND 要求には、識別名とパスワードが必要です。この識別名とパスワードは、安全な接続を介して単純な BIND 要求としてディレクトリ サーバーに送信する必要があります。
  • 定義済みの SASL メカニズムを使用する SASL BIND 要求。メカニズムはサーバーごとに異なり、GSSAPI から PLAIN までさまざまです。

BIND 要求を受信すると、ディレクトリ サーバーは接続の認証状態を即座に匿名に変更し、BIND 要求を処理します。要求を正常に処理できる場合、ディレクトリ サーバーは、0 の整数結果コードを含む BIND 応答で LDAP に応答します。これは、識別名またはユーザー名が正常に認証されたことを示します。

Web アプリケーションは、何らかのメカニズムを使用して認証状態を維持し、認証状態が変化したときにディレクトリ サーバーに BIND 要求を発行する必要があります。これは、セッション タイムアウトまたはその他のメカニズムである可能性があります。選択した方法は、ユーザーが変更できないようにする必要があります。

要約すると、ディレクトリ サーバーを使用して認証資格情報を確認し、セッション フレームワークを使用して認証状態を管理します。

編集:

これは物議を醸す答えだったようです。

  • Cookie を使用しても、ブラウザーで Cookie が無効になっている場合は処理されず、セッションを使用するときに認証状態を維持するために Cookie は必要ありません。
  • セッションはパスワードを必要とせず、パスワードなどの機密情報をメモリやセッションに保存する必要もありません。アプリケーションは、認証状態が期限切れになった場合 (ある場合) またはセッションが期限切れになった場合 (ある場合) に、パスワードを要求する必要があります。
于 2012-08-12T15:59:23.067 に答える