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