ロール・ベースの許可
呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を使用します。
次の図は、許可中に使用されるプロセスを表しています。

Web クライアントからの Web リソース・アクセスは、Web コラボレーターによって処理されます。 Java™ クライアント (エンタープライズ Bean またはサーブレット) からの Enterprise JavaBeans (EJB) リソース・アクセスは、 EJB コラボレーターによって処理されます。EJB コラボレーターと Web コラボレーターは、 オブジェクト・リクエスト・ブローカー (ORB) の現行オブジェクトからクライアント・クレデンシャルを抽出します。 クライアント・クレデンシャルは、認証プロセスの際に、ORB Current オブジェクトで受け取ったクレデンシャルとして設定されます。 リソースと受信されたクレデンシャルは WSAccessManager アクセス・マネージャーに提示され、 クライアントに対して、そのクライアントが要求しているリソースへのアクセスが許可されているかどうかがチェックされます。
- リソース許可モジュールは、指定のリソースに必要なロールを決定するのに役立ちます。 このモジュールは、セキュリティー・ランタイムが アプリケーションの始動時に作成する、 リソースからロールへのマッピング表を使用します。 リソースからロールへのマッピング・テーブルを作成するために、 セキュリティー・ランタイムは、エンタープライズ Bean または Web モジュールのデプロイメント記述子 (ejb-jar.xml ファイルまたは web.xml ファイル) を読み取ります。
- 許可テーブル・モジュールは、ユーザーまたはグループに対するロール表を調べ、
クライアントに必要なロールのいずれかが付与されているかどうかを判断します。ロールからユーザーまたはグループへのマッピング・テーブルは、
許可テーブルとも呼ばれ、アプリケーションの開始時にセキュリティー・ランタイムによって作成されます。
許可テーブルを作成するために、セキュリティー・ランタイムが、必要に応じてアプリケーション・バインディング・ファイル (ibm-application-bnd.xmi または ibm-application-bnd.xml) を読み取ります。
アクセス許可時に Security Access Facility (RACF® など) を使用して EJBROLE プロファイルにアクセスする際は、許可テーブルを作成することもできます。
サポートされる構成: IBM® 拡張ファイル およびバインディング・ファイルの場合、.xmi または .xml ファイル名拡張子は、Java EE 5 より前のアプリケーションまたはモジュールを使用しているか、 あるいは Java EE 5 以降のアプリケーションまたは モジュールを使用しているかによって異なります。IBM 拡張 ファイルまたはバインディング・ファイルは、ibm-*-ext.xmi または ibm-*-bnd.xmi という名前です。 ここで * は拡張ファイルまたはバインディング・ファイルのタイプ (app、application、ejb-jar、 または web など) です。以下の条件が適用されます。
ただし、Java EE 5 以降のモジュールが、Java EE 5 より前のファイルを含み .xmi ファイル名拡張子を使用する アプリケーション内に存在することは可能です。
ibm-webservices-ext.xmi、ibm-webservices-bnd.xmi、ibm-webservicesclient-bnd.xmi、ibm-webservicesclient-ext.xmi、 および ibm-portlet-ext.xmi ファイルは、引き続き .xmi ファイル拡張子 を使用します。
sptcfg
呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を使用します。 許可情報は、いろいろな方法で保管できます。 例えば、リソースごとに、 アクセス制御リストを保管することができます。 ここには、ユーザーおよびユーザー特権のリストが含まれています。 もう 1 つの保管方法は、リソースのリストとそれに対応する特権を各ユーザーに関連付けることです。 このリストは、可能性リストと呼ばれます。
WebSphere® Application Server では、Java 2 Platform, Enterprise Edition (J2EE) 許可モデルを使用します。このモデルでは、許可情報は以下のように編成されています。
アプリケーションのアセンブル時に、メソッドを起動する許可が、1 つ以上のロールに認可されます。 ロールは、一連の許可です。 例えば、銀行用アプリケーションの場合、ロールには、テラー、統括者、クラーク、 およびその他の銀行業関連の地位が含まれます。 テラーのロールは、 口座内のお金の管理に関連するメソッド (例えば、 預金の引き出しや預け入れのメソッド) を実行するための許可に関連付けられています。 テラーのロールには、口座を閉じる許可は付与されていません。 この許可は、スーパーバイザーのロールに与えられています。 アプリケーションのアセンブラーは、各ロールに対するメソッド許可のリストを定義します。このリストは、 アプリケーションのデプロイメント記述子に保管されます。Java EE7 以降では、特殊ロール名 "**" が導入されています。このロールは、ユーザーが認証されるとアクセス権限が付与されることを示します。
AllAuthenticatedUsers、AllAuthenticatedInTrustedRealms、および Everyone の 3 つの特別サブジェクトは、J2EE モデルでは定義されません。 特別サブジェクトは、ユーザー・レジストリーの外部で定義されている製品定義エンティティーです。 このエンティティーは、レジストリー内のユーザーまたはグループのクラスを総称して表すのに使用されます。
- AllAuthenticatedUsers サブジェクトは、認証されているすべてのユーザーに対して、保護されている メソッドへのアクセスを許可します。 ユーザーが正常に認証されるかぎり、そのユーザーは、保護リソースへのアクセスを許可されます。
- AllAuthenticatedInTrustedRealms サブジェクトは、すべての認証済み外部ユーザー (他のレルムにバインドされているユーザー) が、保護されたメソッドにアクセスするのを許可します。 ユーザーが正常に認証されるかぎり、そのユーザーは、保護リソースへのアクセスを許可されます。
- Everyone サブジェクトは、保護リソースへの無制限アクセスを許可しています。ユーザーは、認証せずにアクセスできます。 つまり、この特別なサブジェクトは、 リソースが保護されていない場合と同じように、protected メソッドへのアクセスを提供します。

アプリケーションのデプロイメント時に、実ユーザーまたはユーザーのグループがロールに割り当てられます。 あるユーザーがあるロールに割り当てられると、そのユーザーは、そのロールに認可されるすべてのメソッドの許可を取得します。
ご使用の環境に応じて、いくつかの制限が存在している場合があります。例えば、SAF を使用している場合、検査は常に SAF データベースと照合して行われます。
指定されたロールと照合して行われるアクセス検査が開始する前に認証が完了していない場合は、デフォルトの SAF ID を使用して検査が行われます。
com.ibm.SAF.authorization プロパティーに有効なデフォルトのユーザー ID が構成されていない場合、アクセスは認
可されません。
アプリケーションのデプロイヤーは、
個々のメソッドを理解している必要はありません。
アプリケーションのアセンブラーは、ロールをメソッドに割り当てることによって、
アプリケーションのデプロイヤーの作業を単純化します。
デプロイヤーは、一連のメソッドを使って作業するのではなく、
メソッドのセマンティック・グループ化を表すロールを使って作業します。
管理者は、これらのロールの管理に責任があります。
ユーザーを複数のロールに割り当てられることが可能です。 この場合、ユーザーに付与された許可は、それぞれのロールに与えられた許可の結合体となります。 さらに、認証メカニズムがユーザーのグループ化をサポートしている場合、 グループにロールを割り当てることが可能になります。 あるグループをあるロールに割り当てることは、個々のユーザーをロールに割り当てるのと同じ効果を持ちます。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- 許可検査時のパフォーマンスが向上する。通常は、ユーザー数よりグループ数の方がはるかに少なくなります。
- リソース・アクセスの制御にグループのメンバーシップを使用することにより、柔軟性が向上します。
- 製品環境の外側で、グループにユーザーを追加したり、グループからユーザーを削除したりすることができる。 WebSphere Application Server のロールに対してユーザーを追加または除去するより、このアクションの方が好まれます。変更内容を有効にするには、エンタープライズ・アプリケーションを停止してから再始動します。このアクションは、実稼働環境では悪影響を及ぼす場合があります。
デプロイメント時のベスト・プラクティスは、
ロールに対して、個々のユーザーではなく、グループを割り当てることです。許可に SAF EJBROLES ではなくバインディングを使用していて、
バインディング値を変更する必要がある場合は、
サーバーを再始動して新しい値を有効にする必要があります。
SAF EJBROLES を使用している場合には、アプリケーション・サーバーは自動的に変更を検出します。
詳しくは、
ロール・ベースの許可の System Authorization Facility を参照してください。
実行時に、WebSphere Application Server は、 ユーザーの識別情報、およびユーザーからロールへのマッピングに基づき、着信要求を許可します。ユーザーが、メソッドを実行する許可を持っている何らかのロールに属している場合、着信要求は許可されます。 ユーザーが許可を持つどのロールにも属していない場合は、要求は拒否されます。
- getCallerPrincipal: このメソッドは、ユーザー識別情報を取得します。
- isCallerInRole: このメソッドは、ユーザー識別情報を特定のロールに照らし合わせて検査します。
- getRemoteUser
- isUserInRole
- getUserPrincipal
これらのメソッドの目的は、エンタープライズ Bean メソッドと同じです。
J2EE セキュリティー許可モデルについて詳しくは、Web サイト http://java.sun.com を参照してください。