10g（10.1.3.4.0）
B50832-01
 目次 |
 索引 |
| Oracle Containers for J2EE
セキュリティ・ガイド
10g（10.1.3.4.0） B50832-01 |
|
この章では、JavaおよびJ2EEのアプリケーションとともに使用できる標準的なセキュリティ・モデルの概要について説明します。この章の内容は次のとおりです。
J2EEでは、アプリケーションを基礎となるセキュリティ・インフラストラクチャから切り離す、コンテナ管理セキュリティ用の宣言による許可モデルを定義します。認可ポリシー（リソースとユーザーまたはロール間の関連付け）は、アプリケーション・コード内ではなく、アプリケーションのデプロイメント・ディスクリプタ内で静的に表現されます。認可はロールベースであるため、アクセスレベルで付与され、通常、WebのURLやEJBメソッドなどのリソースを保護します。
この項では、次のJ2EEセキュリティ機能について説明します。
この項では、Webアプリケーションのセキュリティ（主に宣言によるセキュリティ構成）について説明します。より高度なプログラム機能を実行するため、APIについても説明します。APIを使用すると、セキュリティ機能を実行時に決定できます。
内容は次のとおりです。
いくつかの標準認証方式を使用して、J2EE Webアプリケーションにアクセスできます。
Basic認証では、シングル・サインオンの実装を介さずに、ユーザー名とパスワードがユーザーに対して直接要求されます。
Digest認証メカニズムでは、クライアントが自己認証を行うために示すパスワードが、MD5ダイジェストを使用して暗号化されます。これは、リクエスト・メッセージで送信されます。ユーザーからは、Digest認証はBasic認証と同じように動作するように見えます。（OC4Jでは、Digest方式は、外部LDAPプロバイダやカスタム・プロバイダの場合はサポートされません。）
ユーザーがフォームベース認証を使用して保護リソースにアクセスしようとすると、OC4Jはアプリケーション固有のログイン画面を表示し、ユーザー名とパスワードを要求します。
この方式はSecure Sockets Layer（SSL）とともに使用され、HTTPSを介してクライアントが認証されます。ユーザーは公開鍵証明を持っている必要があります。
|
注意
|
J2EEセキュリティ・モデルの場合、保護するWebリソースはURLパターンによって識別されます。これは、Webアプリケーションのweb.xmlファイルで指定されます。次に示すのは、アプリケーションのURLパターン/resourceでリソースを保護する構成の抜粋です。
<web-resource-collection> <web-resource-name>resource access</web-resource-name> <url-pattern>/resource</url-pattern> </web-resource-collection>
これは、web.xmlのセキュリティ制約の一部です。これにより、リソースへのアクセスを許可されているJ2EE論理ロールも指定されます。J2EE仕様に記載されているJ2EE論理ロールには、開発者（アプリケーション・コンポーネント・プロバイダ）、アセンブラ、デプロイヤ、システム管理者などがあります。
たとえば、J2EEロールsr_developersがweb.xmlファイルで宣言されているとします。このロールによるリソースへのアクセスを許可するセキュリティ制約は、次のようになります。
<security-constraint> <web-resource-collection> <web-resource-name>resource access</web-resource-name> <url-pattern>/resource</url-pattern> </web-resource-collection> <!-- authorization --> <auth-constraint> <role-name>sr_developers</role-name> </auth-constraint> </security-constraint>
これにより、この後のOC4J固有の構成手順で、sr_developersロールを適切なデプロイ・ロール（セキュリティ・プロバイダに定義されているロール）にマップすることができます。
WebアプリケーションからEJBへのコールの場合、デフォルト・モードとして、Webクライアントのセキュリティ・アイデンティティがEJBコンテナに伝播されます。
状況によっては、WebコンテナやEJBコンテナに認識されていないWebクライアントによるコールを、Webコンテナが許可しなければならない場合があります。これには、インターネットからリソースへのアクセスを許可する場合など、コンテナに認証されていないWebクライアントをサポートするシナリオも含まれます。
このような状況の場合、<servlet>要素の<run-as>サブ要素を使用して、Webアプリケーションのweb.xmlファイルに対して、みなし実行識別性を指定することができます。
<run-as> <role-name>sr_developers</role-name> </run-as>
Webコンテナは、コールのセキュリティ・アイデンティティをサーブレットからEJBレイヤーに伝播します。このとき、<run-as>要素に指定されたロールが使用されます。このロールは、<security-role>要素を使用して事前に宣言されている必要があります。伝播されたアイデンティティは、みなし実行識別性によって非表示になります。
高度な使用方法として、標準的なJ2EEプログラム機能があります。この機能により、Webアプリケーションを使用してユーザーに関する情報を取得できます。次のメソッドは、ユーザーによるリソースへのアクセスが許可されるかどうかを判断する際に使用できます。
Webアプリケーションで使用できるのは、javax.servlet.http.HttpServletRequestインスタンスに含まれる次のメソッドです。
Principal getUserPrincipal()リクエストを作成する認証対象ユーザーの名前が含まれるプリンシパル・オブジェクト（ユーザーが認証されていない場合はnull）を返します。
サーブレットとEJB間のアイデンティティ伝播が使用されている場合、コール元サーブレットのgetUserPrincipal()メソッドによって返されるプリンシパル名は、EJBのgetCallerPrincipal()メソッドによって返されるものと同じです。
String getRemoteUser()リクエストを送信した認証対象ユーザーのログイン名（ユーザーが認証されない場合はnull）を戻します。
boolean isUserInRole(String rolename)リクエストを送信した認証対象ユーザーが指定されたロールのメンバーであるかどうかを判別します。
|
関連項目
|
この項では、EJBのセキュリティ（主に宣言によるセキュリティ構成）について説明します。より高度なプログラム機能を実行するため、APIについても説明します。APIを使用すると、セキュリティ機能を実行時に決定できます。
内容は次のとおりです。
リモート・コンテナ内のEJBにアクセスする場合は、EJBにアクセスしているクライアントの認証が必要です。
jndi.propertiesファイルのユーザー設定とパスワード設定を使用して資格証明を渡すことができます。
javax.naming.InitialContextインスタンスを使用して資格証明を渡すことができます。このインスタンスは、リモートEJBを検索する際に作成されます。
また、ORMISが使用されている場合（ORMIはSecure Sockets Layerとともに使用）、CLIENT-CERT認証とEJBを併用できます。
J2EEセキュリティ・モデルの場合、保護するEJBリソースは、そのメソッド名または特定のEJB内にある名前マスクによって識別されます。これは、EJBのejb-jar.xmlファイルで指定されます。次の例は、PurchaseOrder Beanのすべてのメソッドを保護する構成を抜粋したものです。
<method> <ejb-name>PurchaseOrder</ejb-name> <method-name>*</method-name> </method>
これは、ejb-jar.xml内にあるメソッド・パーミッションの一部です。これにより、リソースへのアクセスを許可されているJ2EE論理ロールも指定されます。J2EE仕様に記載されているJ2EE論理ロールには、開発者（アプリケーション・コンポーネント・プロバイダ）、アセンブラ、デプロイヤ、システム管理者などがあります。
次の例では、ロールmyMgrによるPurchaseOrder EJBの任意のメソッドへのアクセスが許可されます。
<method-permission> <role-name>myMgr</role-name> <method> <ejb-name>PurchaseOrder</ejb-name> <method-name>*</method-name> </method> </method-permission>
これにより、この後のOC4J固有構成手順で、myMgrロールを適切なデプロイ・ロール（セキュリティ・プロバイダに定義されているロール）にマップすることができます。
ejb-jar.xmlデプロイメント・ディスクリプタには、EJBに対するみなし識別性指定を指定できます。これは、あるEJBが別のEJBをコールする際に、アイデンティティ伝播と連携して使用できます。みなし識別性は、伝播されるアイデンティティを非表示にし、コールされたEJBにまとめて適用され、メソッドを実行する場合のアイデンティティとして使用されます。このアイデンティティは、<security-role>要素を使用して事前に宣言されているJ2EE論理ロールになります。
この場合、<security-identity>要素の<run-as>サブ要素を次のように使用します。
<run-as> <role-name>admin</role-name> </run-as>
高度な使用方法として、標準的なJ2EEプログラム機能があります。この機能により、EJBを使用してユーザーに関する情報を取得できます。次のメソッドは、コール元によるリソースへのアクセスが許可されるかどうかを判断する際に使用できます。
EJBアプリケーションで使用できるのは、javax.ejb.EJBContextインスタンスに含まれる次のメソッドです。
Principal getCallerPrincipal()コール元を識別するプリンシパル・オブジェクトを戻します。
サーブレットとEJB間のアイデンティティ伝播が使用されている場合、コール元サーブレットのgetUserPrincipal()メソッドによって返されるプリンシパル名は、EJBのgetCallerPrincipal()メソッドによって返されるものと同じです。
EJB間のアイデンティティ伝播が使用されている場合、クライアントのアイデンティティは、コール連鎖の上位から下位に向かってすべてのEJBに伝播され、getCallerPrincipal()によって返されるプリンシパル名は、コール連鎖のすべてのEJBに対するプリンシパル名と同じものになります。ただしこれは、subject.propagationパーミッション（「サブジェクト伝播のためのRMIパーミッションの付与」を参照）がすべての認証ユーザーに対して順に付与されていることを前提としています。
boolean isCallerInRole(String rolename)コール元が指定されたロールのメンバーであるかどうかを判別します。
J2EEにおけるアイデンティティ伝播とは、オリジナルのWebモジュールまたはEJBによって起動されるEJBに対して、WebモジュールまたはEJBからセキュリティ・アイデンティティを転送することです。
通常、伝播用のモデルには次の2つがあります。
通常、中間コンテナはターゲット・コンテナによって信頼されている必要があります。これは、伝播されたアイデンティティを認証する際に、ターゲット・コンテナはデータを使用できないためです。伝播されたアイデンティティはisCallerInRole()などの認可チェックに使用されるため、信頼されたアイデンティティである必要があります。
OC4Jの場合、アイデンティティ伝播はサブジェクト伝播と呼ばれます。
|
関連項目
|
Java 2セキュリティ・モデルは、Oracle Application Serverのセキュリティの一部としてサポートされています。ただし、OC4J自体ではなく、基礎となるJDKに実装されています。
このセキュリティ・モデルにより、開発者や管理者にとっては、エンタープライズ・コンポーネント、サーブレットおよびアプリケーションのセキュリティの様々な側面の制御が向上します。Java 2セキュリティ・モデルは機能ベースであり、保護ドメインを設定し、それに対するセキュリティ・ポリシー（「Java 2認可: Java 2セキュリティ・ポリシー」を参照）を設定できます。
ただし、Java 2セキュリティ・モデル自体にいくつかの制限があります。デプロイメント・ディスクリプタにおいては宣言的であるのとは異なり、Java2セキュリティ・モデルはアプリケーション・コードに基づいています。また、ポリシー管理APIも含まず、スケーラビリティが高くないファイルベース実装を使用します。
ここでは、Java 2セキュリティ・モデルの特徴と機能について説明します。
コードを実行する一連のパーミッションを適用することにより、コードベースのセキュリティは、アプリケーションが実行できる操作を制限します。これにより、信頼されないコードや悪意あるコードのアクションからの保護を行い、次のような制限を実行できます。
コードベースのセキュリティは、ユーザーやユーザー・ロールに基づいていないという点で、ロールベースのセキュリティとは異なります。パーミッションは、コードの取得元やデジタル署名の有無（および署名者）など、コードの特性に基づいて付与されます。
コードベースとは、次の例のようにコードの場所を示すURLのことです。
file:（ローカル・ファイル・システム上の任意のファイル）
http://*.oracle.com（oracle.comの任意のホスト上の任意のファイル）
file:${j2ee.home}/lib/oc4j-internal.jar
コードソースは、コードベースの概念を拡張するものです。その場所で生成された署名付きコードを検証する証明書の配列（Javaキーストアに格納）をオプションで含むことができます。コードソースは、java.security.CodeSourceインスタンスによって表され、java.net.URLインスタンスとjava.security.cert.Certificateインスタンスの配列を指定することにより作成されます。
標準的なCodeSourceクラスには、次のメソッドが含まれています。
Certificate[] getCertificates()コードソースに関連付けられた証明書の配列を返します。
URL getLocation()このコードソースに関連付けられたURLの場所を返します。
boolean equals(Object)指定されたオブジェクト（通常はコードソース・オブジェクト）とこのコードソース・オブジェクトが一致するかどうかを比較します。2つのコードソースの場所が同じで、一連の証明書が同じである場合、これらのコードソースは等しいとみなされます。その際、証明書の順序は同じである必要はありません。
boolean implies(CodeSource)一連の比較を実行し、このコードソースが指定されたコードソースを暗黙的に定義しているかどうかを確認します。たとえば、次に示す場所のコードソースがあり、null証明書が指定されている場合、コードソースの場所はhttp://java.sun.com/classes/foo.jarとして暗黙的に定義され、null証明書が指定されます。
http: http://*.sun.com/classes/* http://java.sun.com/classes/- http://java.sun.com/classes/foo.jar
パーミッションは、Java 2セキュリティ・モデルの基礎となります。すべてのJavaクラスには（ローカルで実行するかリモートでダウンロードするかに関係なく）、そのクラスに使用可能なパーミッション・セットを定義するように構成されたセキュリティ・ポリシーが適用されます。各パーミッションは特定のリソースへの特定のアクセス権を表します。
java.security.Permissionクラスは、指定されたリソースへのアクセス権、およびこのリソースに対する指定アクションへのアクセス権（オプション）を表す抽象クラスです。このクラスの主要メソッドはimplies(Permission permission)です。このメソッドでは、指定されたパーミッションのアクションが、このメソッドのコールに使用されたパーミッション・インスタンスのアクションで暗黙的に定義されているかどうかをチェックします。
一般的なパーミッション・タイプを表すクラスは次のとおりです（いずれもPermissionを直接的または間接的に拡張したものです）。
java.security.AllPermission
java.lang.RuntimePermission（リソース・ターゲットのみを含む）
java.io.FilePermission（リソースおよびアクションを含む）
表2-1は、Javaパーミッション・インスタンスの特性を示したものです。
| 要素 | 説明 | 例 |
|---|---|---|
|
クラス名 |
パーミッション・クラス |
|
|
ターゲット |
このパーミッションが適用されるターゲット名（リソース） |
ディレクトリ |
|
アクション |
このターゲットに関連したアクション |
ディレクトリ |
保護ドメインにより、パーミッションがコードソースに関連付けられます（「コードベースのセキュリティ」を参照）。保護ドメインを決定するのは、現在有効なポリシーです。Policyクラスのデフォルト実装では、保護ドメインはファイル内の1つの権限エントリです。
各Javaクラスは、ロード時に保護ドメインに関連付けられます。具体的には、ロードされるクラスはすべてjava.security.ProtectionDomainインスタンスに関連付けられます。この保護ドメインに付与されるパーミッションは、静的にバインドするか、アクセス制御チェックが行われたときに動的に決定することができます。各保護ドメインには、JVMの起動時に、構成済のセキュリティ・ポリシーに基づいて一連のパーミッションが割り当てられます。
ProtectionDomainインスタンスには、1つ以上のコードソースが含まれます。また、このインスタンスには、コードを実行するユーザー、クラス・ローダー参照およびPermissionオブジェクトのコレクションを表すパーミッション・セット（java.security.PermissionCollectionインスタンス）を記述するPrincipal配列を含めることもできます。
図2-1は、コード、保護ドメイン、パーミッション・セットの関係を示したものです。それぞれ次のようになります。
e.jar、c.class、r.class、i.jarのそれぞれのコードソースを、パーミッション・セット1に関連付けます。
s.class、u.jar、t.class、y.classのそれぞれのコードソースを、パーミッション・セット2に関連付けます。
Java 2の場合、ポリシーとは、実行するコードとそのコードに付与されるリソース・アクセス権限の間で行われるマッピングのことです。ポリシーの要素には、コードソース、パーミッション、保護ドメインなどがあります。これらについては、すべて前の項に記載されています。
J2SE実装の場合、ポリシーはjava.security.Policyインスタンスとして表されます。通常、このクラスとJava 2セキュリティ・モデルは、OC4J自体ではなく、基礎となるJDKに実装されます。
コードベースのパーミッションの場合、Java 2ポリシーは、java.policyやjava2.policyなど（通常の場合の例）の.policyファイル内で宣言されます。ポリシーには、コードベースへのパーミッション権限のコレクションが含まれ、キーストアへの参照を含めることもできます（「鍵の暗号化および交換」を参照）。Java 2ポリシー・ファイルは、通常次の場所にあります。
JAVA_HOME/lib/security/java.policy
USER_HOME/java.policy
ORACLE_HOME/j2ee/home/config/java2.policy（セキュリティ・マネージャを使用してOC4Jを起動すると、関連するパーミッションがこの場所のファイルに格納されます。）
セキュリティ・マネージャ（java.lang.SecurityManagerインスタンス）を使用すると、アプリケーションでJava 2セキュリティ・ポリシーを実装できるようになります。セキュリティ・マネージャを使用することにより、実行されたすべての操作に対して、操作の内容や実行の可否をアプリケーションが判断できるようになります。SecurityManagerクラスには多数のcheckXxx()メソッドがあり、各メソッドでは、操作Xxxが許可されているかどうかをチェックし、許可されていない場合には例外をスローします。この中には、要求されたアクセス（所定のパーミッションによって指定されたもの）が現在有効なセキュリティ・ポリシーによって許可されていない場合に例外をスローするインスタンス・メソッドcheckPermission(Permission)も含まれています。
また、アクセス制御の操作および判定には、アクセス・コントローラ（java.security.AccessControllerインスタンス）も関与します。SecurityManagerメソッドcheckPermission(Permission)のデフォルト実装では、実際にはAccessControllerの静的メソッドcheckPermission(Permission)がコールされます。ただし、AccessController.checkPermission(Permission)メソッドの場合、セキュリティ・マネージャは必要ありません。
基本的には、アクセス・コントローラは次を実行するために使用されます。
システム・リソースへのアクセスを制御するアプリケーションの場合、AccessControllerメソッドによって使用される特定のセキュリティ・モデルおよびアクセス制御アルゴリズムを使用する予定であれば、アプリケーションによってこれらのメソッドを起動する必要があります。一方、実行時にインストールされるSecurityManagerのセキュリティ・モデルに従うアプリケーションの場合、アプリケーションによって、SecurityManagerインスタンスの対応するメソッドを起動する必要があります。
比較すると、SecurityManagerはアクセス制御の中心点の概念を表すのに対し、AccessControllerは、doPrivileged()メソッド（有効な権限を使用して、特定の権限を必要とする指定された権限アクションを実行する）などの特別な機能を持つ特定のアクセス制御アルゴリズムを実装するものです。
アクセス制御コンテキスト（java.security.AccessControlContextインスタンス）の概念もあります。アクセス制御コンテキストを使用すると、特定のセキュリティ・コンテキストに基づいてリソースへのアクセスを制限できます。たとえば、特定の保護ドメイン・インスタンスの配列からアクセス制御コンテキストを作成できます。AccessControlContextクラスは、checkPermission(Permission)メソッドも定義します。この場合このメソッドは、現在の実行スレッドのコンテキストではなく、コール元であるAccessControlContextインスタンスに基づいてアクセスを決定します。したがって、特定のコンテキストと関連するセキュリティ・チェックを異なるコンテキストから実行する必要がある場合に、AccessControlContextインスタンスを使用すると便利です。
|
重要
Java 2ポリシーを使用するには、セキュリティ・マネージャを指定して有効にする必要があります（「Java 2セキュリティ・マネージャおよびポリシー・ファイルの指定」を参照）。これにより、JDKおよび |
Java Authentication and Authorization Service（JAAS）は、アプリケーションでユーザーの認証とアクセス制御の強化に使用されるJavaパッケージです。JAASは、Java 2セキュリティを補完するように設計されています。認可は、実行するコード（Java 2のコードベース・セキュリティ）と、コードの実行者（サブジェクトベースのセキュリティ）に基づいて行われます。
JAASには、標準のPluggable Authentication Module（PAM）フレームワークのJavaバージョンも実装されます。これにより、アプリケーションは認証サービスから独立した状態を維持でき、カスタム認証モジュールの使用がサポートされます。
JAASによりJava 2セキュリティ・モデルのアクセス制御アーキテクチャが拡張され、サブジェクトベースの認可がサポートされます。また、JAASでは、デプロイメント・ディスクリプタ内での宣言によるセキュリティ設定がサポートされるので、コードベースのセキュリティ設定に制限されることがありません。
OC4Jには、スケーラブルなJAASプロバイダが用意されています。OC4Jは、密な認可用の標準メカニズムとして、独自のメカニズムではなくJAASを使用します。OC4Jは、Webベース・アプリケーションとEJBベース・アプリケーションの両方に対してJAAS認可をサポートします。
次に示す項で、JAASの特性と機能について説明します。
プリンシパルとは、特定のアイデンティティ（frankという名前のユーザーやhrという名前のロールなど）です。プリンシパルは、java.security.Principalインタフェースを実装するクラスのインスタンスとして表されます。プリンシパル・クラスでは、そのクラスの各インスタンスの一意名を含むネームスペースを定義する必要があります。
サブジェクトは、ユーザー、コンピュータまたはプロセスなど、コンピューティング・サービスを使用する単一ユーザーの関連情報のグループを表します。この関連情報には、サブジェクトのアイデンティティとロール、その他のセキュリティ関連属性（パスワード、暗号キー、その他の資格証明など）が含まれます。サブジェクトは、javax.security.auth.Subjectクラスのインスタンスとして表されます。
ユーザーが認証されると、Subjectインスタンスは認証されたユーザーを表すようになり、次に、適切なPrincipalインスタンスがこのSubjectインスタンスに追加されます。Principalインスタンスは、認証されたユーザーが特定の権限アクションを実行することを認可するために使用されます。
JAAS Pluggable Authenticationフレームワーク内では、アプリケーション・サーバーと基礎となる認証サービスは相互に独立した状態を維持します。認証サービスは、アプリケーション・サーバーまたはアプリケーション・コードに変更を加えずに、JAASログイン・モジュールを介してプラグインできます。ログイン・モジュールの主な役割は、提供された資格証明（たとえばパスワード）に基づいてユーザーを認証すること、および適切なプリンシパル（たとえばロール）をサブジェクトに追加することです。使用できるJAASログイン・モジュールの種類には、プリンシパル・マッピング用モジュール、資格証明マッピング用モジュール、Kerberosモジュールがあります。
ログイン・モジュールは、javax.security.auth.spi.LoginModuleインタフェースを実装するクラスのインスタンスで、特定タイプの認証を提供するためにアプリケーションにプラグインされます。
このフレームワーク内では、（たとえば、ユーザーがアプリケーションにログインしようとしたときに）ユーザー、ロールまたはコンピューティング・サービスなどのサブジェクトの認証に使用する基本メソッドがjavax.security.auth.login.LoginContextクラスで提供されます。アプリケーションでは、このクラスが、名前と（後述する）コールバック・ハンドラを使用してインスタンス化されます。サブジェクトがアクセスしようとしているアプリケーションによってLoginContextインスタンスのlogin()メソッドが起動されると、LoginContextインスタンスは、渡された名前を採用するメカニズムを使用して構成設定を参照し、アプリケーションに対して起動する適切なログイン・モジュールを決定します。
図2-2に、この概要とログイン・モジュールの機能を示します。
コールバック・ハンドラは、javax.security.auth.callback.CallbackHandlerインスタンスであり、ログイン・モジュールがユーザーと対話してログイン情報を取得できるようにします。CallbackHandlerによって指定される唯一のメソッドは、handle(Callback[])メソッドです。このメソッドは、java.security.auth.callback.Callbackインタフェースを実装するクラスのインスタンスであるコールバックの配列を取ります。コールバックでは、基礎となるセキュリティ・サービスから要求された情報は取得または表示されません。リクエストをアプリケーションに渡し、必要に応じて、要求された情報をセキュリティ・サービスに戻すのみです。javax.security.auth.callbackパッケージ内のコールバック実装には、ユーザー名を処理する名前コールバック・ハンドラ（NameCallback）、パスワードを処理するパスワード・コールバック・ハンドラ（PasswordCallback）およびログイン・フォームにあるユーザー名フィールドやパスワード・フィールド以外の任意のフィールドを処理するテキスト入力コールバック・ハンドラ（TextInputCallback）があります。
様々なログイン・モジュールを異なるアプリケーションで構成したり、単一のアプリケーションで複数のログイン・モジュールを使用できます。JAASフレームワークでは、アプリケーション用に構成されたログイン・モジュールを調整するために2段階の認証プロセスが定義されています。
カスタムまたは外部（サード・パーティ）のログイン・モジュールを、指定のアプリケーションと一緒に使用することができます。Oracleには、ログイン・モジュールとして、RealmLoginModule（ファイルベースおよびLDAPベースのプロバイダ用）、LDAPLoginModule（外部LDAPプロバイダ用）、CoreIDLoginModule（Oracle Access Manager用）およびDBTableOraDataSourceLoginModule（データベース・アイデンティティ・ストアを使用するため）が用意されています。
JAAS PAMアーキテクチャを使用すると、ログイン・モジュールのスタックを定義することにより、エンタープライズ・アプリケーションの認証メカニズムをカスタマイズできます。ログイン・モジュールはそれぞれ独立し、自分自身のユーザー・リポジトリに対して通信を行います。
javax.security.auth.login.Configurationクラスは、アプリケーションの下位にあるログイン・モジュールの構成を表すための抽象クラスです。Configurationインスタンスは、特定のアプリケーションに使用されるログイン・モジュールと、ログイン・モジュールの起動順序を指定します。Configurationクラスは、適切な実装を提供するために拡張されています。
各ログイン・モジュールに対しては、ログイン・モジュール構成の制御フラグ設定により、ログイン・モジュールが、required、requisite、sufficient、optionalのいずれになるかが決定されます。これらの設定の意味は、Configurationクラスの標準的な機能に基づいています。表9-5を参照してください。
ログイン構成には、制御フラグ設定および各ログイン・モジュール固有のオプション設定とともに、完全修飾されたクラス名によって指定されたログイン・モジュールの順序リストも含まれています。認証は、モジュール・リストの順番に従って実行されます。（OC4Jの場合、この順序は、system-jazn-data.xmlファイルに構成されているログイン・モジュールの順序によって決定されます。）
認証全体は、個々のログイン・モジュールとその制御フラグ設定によって制御されます。
JAASの場合、ポリシーとは、リソースとユーザー間（またはリソースとロール間）の関連付けのことです。JAASをJava 2セキュリティと統合した場合、Policy APIはプリンシパルに基づいて問合せを処理し、デフォルトのポリシー実装はプリンシパルに基づいて権限エントリをサポートします。Java 2セキュリティ・モデルの拡張の場合、アクセス制御は実行するコードのみではなく、コードの実行者にも基づいて行われます。具体的には、ポリシーは認可ルールのリポジトリで、受領者を指定した場合にその受領者に付与されるパーミッションは何か、という質問に答えるための情報が含まれています。
OC4J 10.1.3.x実装の場合、ポリシーはjavax.security.auth.Policyインスタンスによって表されます。このクラスはJDK 1.4では非推奨ですが、OC4J 10.1.3.x実装では完全サポートされており、Sun社のJDKおよびJ2SEでは引き続きサポートされています。
OC4Jの場合、JAASポリシーはsystem-jazn-data.xmlファイルの<jazn-policy>要素内（または、Oracle Identity Managementセキュリティ・プロバイダを使用している場合はOracle Internet Directory内）で宣言されます。（この機能は、Java 2セキュリティ・モデルの.policyファイルの機能に相当するものです。）この宣言により、ユーザーとロールにパーミッションが付与されます。OracleAS JAAS Provider Admintoolを使用してパーミッションの付与や取消しを行うと、宣言は自動的に更新されます。
Subjectクラスには、JAASモデルの認可用として、次のような標準的なメソッドが含まれています。
Object doAs(Subject, PrivilegedAction)指定された権限アクション（有効化された権限を使用して実行される処理）を、指定されたサブジェクトとして実行します。このメソッドは、サブジェクトを（実行するコードソースの）現行スレッドのアクセス制御コンテキスト（AccessControlContextインスタンス）に関連付けます。その際、このアクセス制御コンテキストのパーミッションにサブジェクトのパーミッションを追加し、パーミッションを組み合せて新しいアクセス制御コンテキストを作成します。次に、指定されたアクションと新しいアクセス制御コンテキストを使用して、AccessController.doPrivileged()メソッドがコールされます。
戻されるオブジェクトは、権限アクションのrun()メソッドによって戻されるオブジェクトです。また、チェック済例外をスローする処理用に、java.security.PrivilegedActionのかわりにjava.security.PrivilegedExceptionActionを取るバリエーションもあります。
Object doAsPrivileged(Subject, PrivilegedAction, AccessControlContext)このメソッドの機能はdoAs()メソッドと同じです。ただし、スレッドのアクセス制御コンテキストを使用するかわりに、指定されたアクセス制御コンテキストにおいて、サブジェクトのパーミッションが指定されたコンテキストのパーミッションに追加されます。コードソースがアクセス権限を必要としないように設定する場合に、nullアクセス制御コンテキストを実際に指定するのが、通常の使用方法です。
図2-3は、doAs()メソッドとdoAsPrivileged()メソッドのサンプル・コード・スタックを示したものです。この場合は、パスワード・ファイルを変更します。doAsPrivileged()メソッドでnullアクセス制御コンテキストを渡す場合、パスワード・ファイルにアクセスする十分な権限をサブジェクトに付与する必要があります。
サブジェクトdoAs()メソッドを権限アクションとともに使用する場合、サブジェクトに関連付けられたプリンシパルに対して、必要なパーミッションを付与してください。この場合、OracleAS JAAS Provider Admintoolを使用して付与できます。構成の結果は、system-jazn-data.xmlファイル内の<jazn-policy>要素の下に表示されます。
次の例では、setContextClassLoaderという実行時権限を、myappという名前のPrincipalImplプリンシパルに付与しています。
% java -jar jazn.jar -grantperm sun.security.acl.PrincipalImpl \ myapp java.lang.RuntimePermission setContextClassLoader
これにより、system-jazn-data.xmlファイル内に次の構成が生成されます。
<grant> <grantee> <principals> <principal> <class>sun.security.acl.PrincipalImpl</class> <name>myapp</name> </principal> </principals> </grantee> <permissions> <permission> <class>java.lang.RuntimePermission</class> <name>setContextClassLoader</name> </permission> </permissions> </grant>
|
関連項目
|
ここでは、セキュリティ開発サイクル時の考慮事項について説明します。セキュリティ・モデル間の比較の概要と、アプリケーション開発でセキュリティを確保するための手順を説明します。
この章で説明するJ2EE、Java 2、JAASの各セキュリティ・モデルの相違点の概要は、次のとおりです。
J2EEモデルの場合、認証はコンテナによって管理されます。
J2EEモデルと同じように、認証はコンテナによって管理されます。
またJAASは、カスタム・ログイン・モジュールを使用して認証をカスタマイズできる唯一のモデルでもあります。さらに、複数のユーザー・リポジトリと照合して認証することもできます。
必要に応じて、任意のモデルを使用するか、アプリケーション内のモデルを組み合せることができます。OC4Jの場合、3種類のモデルすべてが完全サポートされています。ニーズが満たされるのであれば、J2EE認可モデルを使用することをお薦めします。これは、管理者やデプロイヤにとって最も単純な方法です。必要に応じてアプリケーションを拡張し、密なコードベース・セキュリティやサブジェクトベース・セキュリティに対して、Java 2セキュリティやJAASセキュリティを使用することができます。
J2EEソフトウェアの開発は、開発-デプロイ-管理というサイクルで行われます。Oracle Application Serverのセキュリティ実装は、このサイクルのデプロイ-管理部分で重要な役割を果します。開発者はセキュリティをプログラムで統合する必要がなくなり、より便利な宣言によるセキュリティ・モデルを使用できます。
次のリストに、セキュアなアプリケーション開発に固有のタスクに重点を置いてJ2EE開発サイクルの概要を示します。
Oracle Application Serverのセキュリティ実装はプログラム・インタフェースを提供しますが、開発者はそれを使用することなくコンポーネントを作成できます。
このプロセスの一部として、アプリケーション・アセンブラは環境に適切なオプションを指定します。
デプロイメント・プロセスの一部として、デプロイヤはJ2EEロールをデプロイメント・ユーザーおよびロールにマップすることができます（「Application Server Controlを介したセキュリティ・ロール・マッピングの指定」を参照）。
このタスクには、アプリケーション・ユーザーからの要求に応じたデプロイメント環境のロールと、ユーザーの作成および管理が含まれます。
Java 2またはJAASの機能を使用した密なコードベースのアクセス制御やサブジェクトベースのアクセス制御には、次のような考慮事項があります。
|
 Copyright © 2003, 2008 Oracle Corporation. All Rights Reserved. |
|