J2EEセキュリティ:コンテナとカスタム

ログインページがWebアプリケーションに初めて追加されて以来、セキュリティは常にWeb上のアプリケーションの成功に不可欠な重要なコンポーネントの1つでした。歴史的に、すべてが手作業でコーディングされていました。各Webアプリケーションには、ユーザーを認証してから承認するカスタムメソッドがありました。開発者は、登録、管理、およびその他の必要な機能のためのコンポーネントも組み込んでいます。かなりのオーバーヘッドがありますが、このアプローチは大きな柔軟性を可能にしました。

Java Authentication and Authorization ServiceであるJAASの出現により、アプリケーションは、それらのタスクを標準化するために活用できる一連のインターフェースと構成を獲得しました。仕様にJAASが追加されたとしても、アプリケーション開発者がカスタムAPIの作成を停止する前に、J2EEには解決すべきいくつかの問題があります。 J2EE標準を使用するか、カスタムソリューションを構築するかを選択するには、それぞれのトレードオフと、もちろん、アプリケーションの要件を知る必要があります。

この記事は、カスタムセキュリティとコンテナセキュリティのどちらを決定するために必要なすべての情報を提供することを目的としています。セキュリティに必要な背景を提供するための最も一般的なアプリケーションセキュリティ機能について説明します。その説明に続いて、仕様によって提供されるJ2EEセキュリティの実装と、カスタムセキュリティを実装する最も一般的な方法について詳しく説明します。それぞれの方法をよりよく理解したら、アプリケーションの要件に最適な方法を選択するための十分な情報が得られるはずです。

コンテナとは何ですか?

さまざまなセキュリティタイプとセキュリティ実装の懸念について説明する前に、どのコンテナを確認しましょうです。コンテナは、アプリケーションが実行される環境です。また、J2EEアプリケーションサーバーと同義です。J2EEコンテナに関しては、J2EEアプリケーションはコンテナ内で実行され、コンテナに関して特定の責任があります。J2EEコンテナにはさまざまな種類があり、さまざまなレベルのJ2EEサポートがあります。ApacheのTomcatは、J2EE仕様のサーブレット(Webアプリケーション)部分のみを実装するWebコンテナです。BEAのWebLogicは完全に準拠したJ2EEアプリケーションサーバーです。つまり、J2EE仕様のすべての側面をサポートし、SunのJ2EE認定テストに合格しています。アプリケーションサーバーが提供するサポートがわからない場合は、ベンダーに詳細を問い合わせてください。

アプリケーションのセキュリティ

始める前にカバーしなければならないもう1つのトピックは、アプリケーションセキュリティと他のタイプのセキュリティの違いです。アプリケーションセキュリティは、アプリケーションによって直接実行されるセキュリティ、またはアプリケーションのユーザーに関してアプリケーションのフレームワークまたはコンテナによって間接的に実行されるセキュリティです。アプリケーションユーザーの例は、オンライン書店にログインしてJavaの本を数冊購入する人です。ネットワークセキュリティやJVMセキュリティなど、他の種類のセキュリティが存在します。これらのセキュリティタイプの一例は、マシン上でJavaプロセスを開始するユーザーです。このホワイトペーパーの残りの部分では、セキュリティについて説明するときは常に、アプリケーションのセキュリティを意味します。他のタイプのセキュリティは、この議論の範囲外に達します。

ここでの焦点は、特にJ2EEセキュリティです。これは、J2EEアプリケーションのユーザー(つまり、呼び出し元)を処理するため、アプリケーションセキュリティの一種です。ユーザーは、オンライン書店を使用している人、または書店アプリケーションの購入サービスを使用する別のアプリケーション(別のオンライン再販業者など)である可能性があります。

アプリケーションのセキュリティ機能

アプリケーションのセキュリティを検討する際の主な機能は、認証、承認、登録、アカウントのメンテナンス(更新)、アカウントの削除/非アクティブ化の5つです。アプリケーションが持つ可能性のあるすべての機能のごく一部にすぎませんが、これらはすべてのアプリケーションにとって最も基本的でかなり標準的なものです。あまり正式ではありませんが、これらの機能は、ユーザーを知る(認証)、ユーザーができることを知る(承認)、新しいユーザーを作成する(登録)、ユーザー情報を更新する(アカウントの保守)、ユーザーを削除する、またはユーザーがアプリケーションにアクセスできないようにすることです。 (アカウントの削除)。

ほとんどのアプリケーションでは、ユーザーまたは管理者がこれらの機能を実行できます。ユーザーがこれらの機能を実行するとき、ユーザーは自分で実行します。管理者は常に他のユーザーに代わってこれらの機能を実行します。

後で説明するように、これらの機能はすべて、認証の場合でも、カスタムソリューションなしでは実行できません。それぞれについて簡単に説明し、概念と、カスタムビルドする必要があるJ2EEに欠けているものをさらに説明します。

認証

認証は、アプリケーションと対話するユーザーを識別するプロセスです。この記事の執筆時点では、J2EE認証はさまざまなソリューションを使用して実装でき、それぞれがJ2EE仕様(バージョン1.0-1.4)の一部として定義されています。認証はこの議論の主要な概念であり、後で詳しく説明します。認証はJ2EE仕様内で最もサポートされているセキュリティ機能であることを理解することが重要ですが、J2EE認証(別名コンテナ認証)を実装するには、通常、カスタムコードまたは構成が必要です。

承認

承認は、ユーザーが特定のアクションを実行する権限を持っていることを確認するプロセスです。J2EEはこのトピックをカバーしていますが、ロールベースの承認に制限されています。つまり、ユーザーに与えられたロールに基づいてアクティビティを制限できます。たとえば、マネージャーの役​​割のユーザーは在庫を削除できますが、従業員の役割のユーザーは削除できない場合があります。

さらに、アプリケーションは、Javaランタイム環境(JRE)/コンテナーとアプリケーションの承認という2つの異なるタイプの承認を検討する場合があります。 JRE /コンテナー許可は、要求を行うユーザーがそうする特権を持っているかどうかを判別するプロセスです。 JRE /コンテナは、コードを実行する前にこれを決定します。例としては、サーブレットを実行する前に、現在のユーザーが(リソースURL制約を介して)サーブレットを実行する権限を持っているかどうかを最初に確認する必要があるJ2EEコンテナがあります。このタイプの承認は、宣言型セキュリティとも呼ばれますこれは、Webアプリケーションの構成ファイルで宣言されているためです。コンテナでサポートされていない限り、宣言型セキュリティは実行時に変更できません。宣言型セキュリティは、J2EEアプリケーションユーザーを承認するためにさまざまな方法で使用できますが、そのトピックはこの説明の範囲外です。 (サーブレット2.3仕様の第12章を参照してください。セクション2は宣言型セキュリティについて説明しており、8はセキュリティ制約の出発点として適しています。)

前述のように、ユーザーは別のアプリケーションまたは単にアプリケーションユーザーである可能性があります。いずれの場合も、JRE /コンテナー許可は各要求中に実行されます。これらの要求は、ブラウザからWebアプリケーションへのHTTP要求、またはリモートEJB(Enterprise JavaBeans)呼び出しである可能性があります。いずれの場合も、JRE /コンテナがユーザーを知っていれば、そのユーザーの情報に基づいて認証を実行できます。

アプリケーションの承認は、アプリケーションの実行時に承認するプロセスです。アプリケーションの承認は、さらに役割ベースの承認とセグメントベースの承認に分類できます。ロールベースのアプリケーション承認の例は、ユーザーが従業員であるか訪問者であるかに基づいて、アプリケーションがさまざまなレベルのマークアップを適用する場合です(つまり、従業員割引)。 J2EEは、ロールベースの承認を実現するためのプログラムセキュリティと呼ばれるAPIを提供します(詳細については、サーブレット2.3仕様の第12章のセクション3を参照してください)。

セグメントベースの承認は、年齢や趣味など、ユーザーの他の属性に基づく承認です。セグメントベースの承認は、特定の属性に基づいてユーザーをセグメントにグループ化するため、このように呼ばれます。J2EEには、セグメントベースの認証を実装する方法がありません。セグメントベースの承認の例は、フォームのボタンが40歳以上のユーザーに表示されるかどうかです。特定のベンダーがこのタイプの認証を提供する場合がありますが、これにより、すべての場合にベンダーロックインが保証されます。

登録

登録は、アプリケーションに新しいユーザーを追加するプロセスです。アプリケーションユーザーが自分で新しいアカウントを作成できる場合や、アプリケーションがこのアクティビティをアプリケーション管理者に制限することを選択する場合があります。J2EE仕様には、アプリケーションが新しいユーザーを追加できるようにするAPIまたは構成がありません。したがって、このタイプのセキュリティは常にカスタムビルドされます。J2EEには、新しいユーザーが登録したコンテナに通知する機能がなく、セッション中も彼女の情報を保持および維持する必要があります。

メンテナンス

アカウントのメンテナンスは、連絡先情報、ログイン、パスワードなどのアカウント情報を変更するプロセスです。ほとんどのアプリケーションでは、アプリケーションユーザーと管理者がメンテナンスを実行できます。J2EE仕様には、アカウント保守用のAPIまたは構成もありません。ユーザー情報が変更されたことをコンテナーに通知するメカニズムがありません。

削除

アカウントの削除は通常、管理ユーザーのみに制限されます。まれに、一部のアプリケーションでは、ユーザーが自分のアカウントを削除できる場合があります。実際、ほとんどのアプリケーションはユーザーを削除しません。アカウントを非アクティブ化するだけで、ユーザーはログインできなくなります。アカウントデータを必要に応じて復活させるのははるかに難しいため、ハードで高速な削除を行うことは通常は嫌われます。J2EEは、アプリケーションからユーザーを削除または非アクティブ化する方法を提供しません。特定のユーザーが非アクティブ化または削除されたことをコンテナーに通知するメカニズムがありません。J2EEには、アカウントが削除されたときにユーザーをアプリケーションからすぐにログアウトするメカニズムもありません。

コンテナ認証とは何ですか?

コンテナ認証は、現在のリクエストを行っているユーザーのIDをコンテナに通知するプロセスです。ほとんどのコンテナでは、このプロセスには、現在のServletRequestオブジェクト、現在の実行スレッド、および内部セッションをユーザーのIDに関連付けることが含まれます。セッションをIDに関連付けることにより、コンテナーは、そのユーザーのセッションが期限切れになるまで、現在の要求と同じユーザーによる後続のすべての要求を同じセッションに関連付けることができることを保証できます。このセッションオブジェクトは通常、HttpSessionオブジェクトと同じではありませんが、前者は後者を作成および維持するために使用されます。同じユーザーによる後続の各要求は、サーブレット2.3仕様の第7章に従って、URL書き換えまたはセッションCookieのいずれかを使用してセッションに関連付けられます。

承認の説明で前述したように、コンテナーが実行するすべてのアクションと、そのユーザーに代わってJREが実行するすべてのアクションは、ユーザーがアクションを実行する権限を持っていることを確認するために注意深くチェックされます。前の例を繰り返すと、コンテナがユーザーに代わってサーブレットを実行するときに、ユーザーがそのサーブレットを実行する権限を与えられたロールのセットに属していることを確認します。 JRE 1.4は、ファイルまたはソケットが開いたときなど、多くのアクションに対してこれらのチェックも実行します。 JRE認証は強力な概念であり、コンテナーへのすべての要求が本質的に安全であることを保証できます。

現在、J2EEは、ユーザー認証を実装するためのいくつかの異なるメカニズムを提供しています。これらには、フォームベース認証、HTTPSクライアント認証、およびHTTP基本認証が含まれます。 JAASは、コンテナーがサポートする必要のある必須の認証方法として含まれています。ただし、仕様は、コンテナがこの機能を提供する方法について厳密ではありません。したがって、各コンテナはJAASに対して異なるサポートを提供します。さらに、JAAS自体はスタンドアロンの認証フレームワークであり、仕様でサポートされているかどうかに関係なく、コンテナ認証を実装するために使用できます。この概念については、後で詳しく説明します。

各認証メカニズムは、ユーザーに関するコンテナー情報を提供する標準的な方法を提供します。私はこれを資格情報の実現と呼びます。コンテナは引き続きこの情報を使用して、ユーザーが存在し、リクエストを行うのに十分な権限を持っていることを確認する必要があります。私はそれを資格認証と呼びます。一部のコンテナーは、資格情報認証をセットアップするための構成を提供し、その他のコンテナーは、実装する必要のあるインターフェースを提供します。

J2EE認証方法

コンテナ認証を実装および構成するための最も一般的な方法のいくつかを簡単に見てみましょう。

フォームベース認証

フォームベース認証を使用すると、任意のHTMLフォームを使用してJ2EEアプリケーションサーバーでユーザーを識別および認証できます。フォームアクションはである必要がj_security_checkあり、2つのHTTPリクエストパラメータ(フォーム入力フィールド)が常にリクエストに含まれている必要があります。一方は呼び出さj_usernameれ、もう一方は呼び出されj_passwordます。フォームベース認証を使用すると、フォームが送信され、ユーザー名とパスワードがサーバーに送信されたときに資格情報が実現されます。

フォームベース認証を使用するJSP(JavaServer Pages)ページの例を次に示します。

 ログインユーザー名を入力します。

パスワードを入力してください: