JDBC レルムは、属性 userNameCol および userCredCol によって定義された列を含む認証用のテーブル構造を指定します。これらは、FORM または BASIC auth-methods にとって意味のあるユーザーとパスワードに対応します。それらは対話型であり、クライアントのユーザーからこれら 2 つの部分を必要とします。
PS - Tomcat 5.5.x を使用しています。
はい、できます。ただし、注意すべき癖がいくつかあります。
ユーザー名の列には、証明書サブジェクトの識別名が文字列として含まれている必要があります。残念ながら、Tomcat がこの文字列を取得するために使用する方法は、実装に依存する結果を生成するため、新しいセキュリティ プロバイダーに切り替えたり、Java ランタイムをアップグレードしたりするだけでも、ユーザー名を新しい形式にマップする必要がある可能性があります。 . 展開をテストして、使用されている形式を確認する必要があります。
具体的には、返された でgetName()が呼び出され、ユーザー名として使用されるを取得します。ドキュメントを読むと、これが最善の方法ではないことがわかります。PrincipalX509Certificate.getSubjectDN()String
最も簡単なセットアップは、「server.xml」ファイルで構成されているTomcat のトラスト ストアにトラスト アンカーをロードすることです。このセットアップでは、信頼できる CA の 1 つのルートであるクライアント証明書チェーンはすべて「認証済み」と見なされます。認証とは、ID が既知であることを意味し、その ID が許可されるものを決定する承認とは異なります。行う。
署名された証明書を持つ人は誰でも認証されるため、アプリケーション内のプライベート リソースを保護するためにロールを設定する必要があります。これは、「web.xml」ファイルでロールに関連付けられたセキュリティ制約を設定することによって行われます。次に、データベースで「ロール」テーブルにデータを入力して、信頼できるユーザーに追加のロールを付与します。
ユーザー テーブルとロール テーブルの関係は、FORM ベースの承認の場合とまったく同じように機能し、信頼できるユーザーに適切なアクセス許可を付与するために使用する必要があります。
は、パスワードを保持JDBCRealmする新しいPrincipalを作成しますが、アプリケーションがこれPrincipalを Tomcat 固有の実装 ( GenericPrincipal ) にダウンキャストしない限り、このプロパティは表示されず、何を入力しても問題ありません。そのコラム。私はお勧めしNULLます。
つまり、JDBCRealmclient-auth で使用する場合、パスワード フィールドは無視されます。これGenericPrincipalには、基礎となるプリンシパルにアクセスする方法がありますが、残念ながら、Principal証明書からの は渡されません。これJDBCRealmは null に設定されます。このシナリオで唯一有用な方法はgetName()(サブジェクト DN を返すことは、非標準の形式である可能性があります) です。
FORM ベースの JDBCRealm (または DatasourceRealm)とまったく同じテーブル構造を使用します。唯一の違いはコンテンツにあります。ユーザー名はサブジェクトの識別名のテキスト表現になり、パスワードはNULLまたは何らかのダミー値になります。