Enterprise JavaBeans と Web アプリケーションの役割およびサーブレット
役割は、Java 2 platform Enterprise Edition (J2EE) アプリケーションに関連付けられています。アプリケーション内のモジュールは、 アプリケーション役割を指す役割参照を使用して、役割を参照します。 Web アプリケーション、サーブレット、または EJB メソッドへのアクセスは、ユーザーまたは呼び出し元を基にしています。 役割は、アセンブル時に Web アプリケーション、およびサーブレットまたはエンタープライズ Bean に関連付けられています。 サーブレットまたは EJB メソッドを使用する必要がある役割は、アプリケーションのデプロイメント記述子で指定されます。
どのユーザーおよびグループがどの役割を持つかは、EJBROLE クラス内の RACF プロファイルを使用して 決定されます (SAF 許可が選択されている場合)。ユーザーが EJBROLE プロファイルのアクセス・リスト内にある場合、ユーザーはその役割を持ちます。グループが EJBROLE プロファイルのアクセス・リスト内にある場合、そのグループ内のユーザーはその役割を持ちます。 EJBROLE プロファイルが ACCESS(READ) を持つ場合、すべてのユーザーがその役割を持ちます。
セキュリティー・ドメインが指定されている場合、このセキュリティー・ドメインは、EJBROLE プロファイルを検査する際に、 WebSphere Application Server for z/OS および RACF が使用するプレフィックスになります。これは、セル・レベルの役割の 細分性を提供します。これを実現するために、アプリケーションで役割を変更する必要はありません。
Test Cell has Security Domain=TEST Production Cell has Security Domain=PROD
例えば、役割 Clerk を使用するアプリケーションは両方のセルでデプロイされます。 テスト・セルでは、ユーザーは EJBROLE プロファイル TEST.Clerk への READ アクセスが必要です。 実動セルでは、ユーザーは EJBROLE プロファイル PROD.Clerk への READ アクセスが必要です。
管理許可用の RACF EJBROLE クラスで定義されるプロファイルは 4 つあります。 管理者、コンフィギュレーター、モニター、およびオペレーターです。 役割マッピング用に RACF を使用する場合、ユーザーに与える管理権限に応じて、 これらのプロファイルのいずれかに対して、RACF ユーザー ID またはグループ READ アクセスを定義する必要があります。
J2EE ベースの役割許可における SAF の使用方法について詳しくは、役割ベースの許可の System Authorization Facility を参照してください。
RACF プロファイルの使用
RACF (あるいは同等のセキュリティー製品) で CBIND、SERVER、お よび STARTED クラスによるサーバー・リソースの保護に使用される、セキュリティー・メカニズムについて理解しておく ことは重要です。 セキュリティー環境を管理する手法を知っておく必要があります。
WebSphere Application Server for z/OS で使用される RACF プロファイルの基本的な情報は、SAF ベースの許可に記載されています。このセクションでは、CBIND、SERVER、および STARTED クラスのプロファイルに関する追加情報について述べます。
ユーザー ID およびグループ ID
CR = コントローラー領域 SR = サーバント領域 CFG = 構成 (グループ) server = サーバーのショー ト・ネー ム cluster = 汎用サーバーの (ショート) ネーム (クラスター遷移名ともいう)
<CR_userid> <CR_groupid>, <CFG_groupid> <SR_userid> <SR_groupid>, <CFG_groupid> <demn_userid> <demn_groupid>, <CFG_groupid> <admin_userid> <CFG_groupid> <client_userid> <client_groupid> <ctracewtr_userid> <ctracewtr_groupid>
WebSphere Application Server for z/OS のリソースを保護するために、許可やアクセス・レベルとあわせて使用される各種のプロファイルは次のとおりです。
CBIND クラス・プロファイルの使用
CBIND クラス・プロファイル - 汎用サーバーへのアクセス CB.BIND.<cluster> UACC(READ); PERMIT <CR_group> ACC(CONTROL) CBIND Class profiles - access to objects in servers CB.<cluster> UACC(READ) PERMIT <CR_group> ACC(CONTROL)
CBIND Class profiles - access to generic servers CB.BIND.<domainId>.<cluster> UACC(READ) CBIND Class profiles - access to objects in servers CB.<domainId>.<cluster> UACC(READ)
CB.CBIND.<cluster> CB.CBIND.<security domain>.<cluster>
CB.<cluster> CB.<security domain>.<cluster>
SERVER クラス・プロファイルの使用
SERVER class profiles – access to controllers using static Application Environments CB.<server>.<cluster> UACC(NONE) PERMIT <SR_userid> ACC(READ) SERVER class profiles – access to controllers using dynamic Application Environments CB.<server>.<cluster>.<cell> UACC(NONE) PERMIT <SR_userid> ACC(READ)
RDEFINE CB.&<server<cluster> UACC(NONE); PERMIT &<SR_userid> ACCESS(READ)この例で、server = サーバー名、cluster = クラスター名またはクラスター遷移名 (クラスターがまだ作成されていない場合)、SR はサーバー領域の MVS ユーザー ID です。
CB.& <server>.&<cluster>.<cell> UACC(NONE); PERMIT &<SR_userid> ACC(READ)この例で、server = サーバー名、cluster = クラスター名またはクラスター遷移名 (クラスターがまだ作成されていない場合)、cell = セルのショート・ネーム、 および SR はサーバー領域の MVS ユーザー ID です。
SERVER クラス・プロファイルは、サーバントが関連コントローラーで権限ルーチンを呼び出すことができるかどうかを 制御します。
CB.<server>.<cluster> CB.<security domain>.<server>.<cluster>
CB.<server>.<cluster>.<cell> 22
STARTED クラス・プロファイルの使用
STARTED クラス・プロファイル - (MGCRE) <<CR_proc>.<CR_jobname> STDATA(USER(CR_userid) GROUP(CFG_groupid)) <demn_proc>.* STDATA(USER(demn_userid) GROUP(CFG_groupid)) STARTED クラス・プロファイル - (ASCRE) <SR_jobname>.<SR_jobname> STDATA(USER(SR_userid) GROUP(CFG_groupid)) IJP 用 STARTED クラス・プロファイル - (MGCRE) <MQ_ssname>.* STDATA(USER(IJP_userid) GROUP(CFG_groupid))
APPL クラス・プロファイルは、認証済みユーザーがセル内で任意のアプリケーションを使用できるかどうかを制御します。 セキュリティー・ドメインが指定されている場合、APPL クラス・プロファイル名はセキュリティー・ドメイン名です。 セキュリティー・ドメインが指定されていない場合、 APPL クラス・プロファイル名は CBS390 です。詳しくは、System Authorization Facility (SAF) のオペレーティング・システムおよびアプリケーション・レベルに関する考慮事項 を参照してください。
シスプレックス内での複数のセキュリティー構成の作成
企業内で論理的 WebSphere Application Server for z/OS セキュリティー・ドメインを 分離するために、指定された RACF データベース内にプロファイルの明確なセットが必要となる場合があります (例えば、テストおよび実動ユーザー)。
Use Security Domain Identifier in RACF Definitions: <Y/N> Security Domain Identifier....................: <domainId>
WebSphere Application Server for z/OS 管理コンソールを使用して、「セキュリティー」>「グローバル・セキュリティー」>「カスタム・プロパティー」の下で、これらの変数を設定します。これにより、セルのディレクトリー内の security.xml ファイルに以下のプロパティーが作成されます。
xmi:id="Property_47" name="security.zOS.domainType" value="cellQualified" required="false"/> xmi:id="Property_48" name="security.zOS.domainName" value="<domain_name>" required="false"/>
これにより、サーバーのディレクトリー内の was.env ファイルに以下の変数が作成されます。security_zOS_domainName=<domain_name> security_zOS_domainType=1
Class domainType=None domainType=cellQualified CBIND CB.clustername CB.domainId.clustername CB.BIND.clustername CB.BIND.domainId.clustername APPL CBS390 domainId EJBROLE ApplicationRoleName domainId.ApplicationRoleName
新規サーバーの新規ユーザー ID およびプロファイルの生成
新規のアプリケーション・サーバーごとに固有のユーザー ID を使用する場合は、これらのユーザー、グループ、およびプロファイルを RACF データベースで定義する必要があります。
Minimalist プロファイルの使用
RACF データ・セットでユーザー、グループ、およびプロファイルの数を最小限にとどめるために、1 つのユーザー ID と 1 つのグループ ID、および汎用性の高いプロファイルを使用して、同一セル内の複数のサーバーに対応できるようにするものです。 この手法は、統合 JMS プロバイダーおよび Network Deployment の構成でも使用できます。