呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を使用します。
次の図は、許可中に使用されるプロセスを表しています。
Web クライアントからの Web リソース・アクセスは、Web コラボレーターによって処理されます。 Java クライアント (エンタープライズ Bean またはサーブレット) からの Enterprise JavaBeans (EJB) リソース・アクセスは、 EJB コラボレーターによって処理されます。 EJB コラボレーターと Web コラボレーターは、 オブジェクト・リクエスト・ブローカー (ORB) の現行オブジェクトからクライアント信任状を抽出します。 クライアント・クレデンシャルは、認証プロセスの際に、ORB Current オブジェクトで受け取ったクレデンシャルとして設定されます。 リソースと受信されたクレデンシャルは WSAccessManager アクセス・マネージャーに提示され、 クライアントに対して、そのクライアントが要求しているリソースへのアクセスが許可されているかどうかがチェックされます。
許可テーブルを作成するために、セキュリティー・ランタイムは、 アプリケーション・バインディング・ファイル ibm-application-bnd.xmi を読み取ります。
アクセス許可時に Security Access Facility (RACF など) を使用して EJBROLE プロファイルにアクセスする際は、許可テーブルを作成することもできます。
呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を使用します。 許可情報は、いろいろな方法で保管できます。 例えば、リソースごとに、 アクセス制御リストを保管することができます。 ここには、ユーザーおよびユーザー特権のリストが含まれています。 もう 1 つの保管方法は、リソースのリストとそれに対応する特権を各ユーザーに関連付けることです。 このリストは、可能性リスト と呼ばれます。
WebSphere Application Server では、Java 2 Platform, Enterprise Edition (J2EE) 許可モデルを使用します。 このモデルでは、許可情報は以下のように編成されています。
アプリケーションのアセンブル時に、メソッドを起動する許可が、1 つ以上の役割に認可されます。 役割は、一連の許可です。 例えば、銀行用アプリケーションの場合、役割には、テラー、統括者、クラーク、 およびその他の銀行業関連の地位が含まれます。 テラーの役割は、 口座内のお金の管理に関連するメソッド (例えば、 預金の引き出しや預け入れのメソッド) を実行するための許可に関連付けられています。 テラーの役割には、口座を閉じる許可は付与されていません。 この許可は、スーパーバイザーの役割に与えられています。 アプリケーションのアセンブラーは、各役割に対するメソッド許可のリストを定義します。このリストは、 アプリケーションのデプロイメント記述子に保管されます。
ただし、作業を行っている環境によって、制約事項は存在しません。
例えば、SAF を使用するときは、SAF データベースに対して常に検査が行われます。
指定された役割に対するアクセス検査の前に認証が完了していない場合は、
デフォルトの SAF ID が検査に使用されます。
com.ibm.SAF.authorization プロパティーに有効なデフォルトのユーザー ID が構成されていない場合、アクセスは認
可されません。
WebSphere Application Server が SAF を使用して構成されている場合、特別サブジェクト (AllAuthenticatedUSers
および Everyone) は無視されます。これらの機能は、SAF 内で使用可能です。この機能は、
RESTRICTED プロパティーを持つ RACF の非認証ユーザー ID の定義よりシミュレートされます。
EJBROLE プロファイルが READ の Universal Access
(UACC) で作成された場合、非認証ユーザー ID 以外のすべての認証ユーザーがアクセスできます。
アプリケーションのデプロイメント時に、実ユーザーまたはユーザーのグループが役割に割り当てられます。 あるユーザーがある役割に割り当てられると、そのユーザーは、その役割に認可されるすべてのメソッドの許可を取得します。
アプリケーションのデプロイヤーは、
個々のメソッドを理解している必要はありません。
アプリケーションのアセンブラーは、役割をメソッドに割り当てることによって、
アプリケーションのデプロイヤーの作業を単純化します。
デプロイヤーは、一連のメソッドを使って作業するのではなく、
メソッドのセマンティック・グループ化を表す役割を使って作業します。
管理者は、これらの役割の管理に責任があります。
ユーザーを複数の役割に割り当てられることが可能です。 この場合、ユーザーに付与された許可は、それぞれの役割に与えられた許可の結合体となります。 さらに、認証メカニズムがユーザーのグループ化をサポートしている場合、 グループに役割を割り当てることが可能になります。 あるグループをある役割に割り当てることは、個々のユーザーを役割に割り当てるのと同じ効果を持ちます。
デプロイメント時のベスト・プラクティスは、
役割に対して、個々のユーザーではなく、グループを割り当てることです。許可に SAF EJBROLES ではなくバインディングを使用していて、
バインディング値を変更する必要がある場合は、
サーバーを再始動して新しい値を有効にする必要があります。
SAF EJBROLES を使用している場合には、アプリケーション・サーバーは自動的に変更を検出します。
詳しくは、
役割ベースの許可の System Authorization Facility を参照してください。
実行時に、WebSphere Application Server は、 ユーザーの識別情報、およびユーザーから役割へのマッピングに基づき、着信要求を許可します。 ユーザーが、メソッドを実行する許可を持っている何らかの役割に属している場合、着信要求は許可されます。 ユーザーが許可を持つどの役割にも属していない場合は、要求は拒否されます。
これらのメソッドの目的は、エンタープライズ Bean メソッドと同じです。
J2EE セキュリティー許可モデルについて詳しくは、 Web サイト http://java.sun.com を参照してください。