許可

管理機能の許可

エンティティーがリソースにアクセスしようとすると、 リソースへのアクセスに必要な権限がそのエンティティーにあるかどうかを許可サービスが判断します。 この概念は、エンティティーがアプリケーションにアクセスする場合でも、管理機能を実行する場合でも同じです。 アプリケーションへのアクセスの許可と、管理機能へのアクセスの許可における主な違いは、ユーザーがどのようにロールにマップされるかという点にあります。 アプリケーションの許可の場合は、 server.xml ファイルまたは ibm-application-bnd.xml/xmi ファイル内の application-bnd エレメントを使用して、ユーザーをロールにマップします。 管理機能の許可については、 server.xml ファイル内の administrator-role エレメントを使用して、ユーザーを管理者ロールにマップします。 管理セキュリティに関する詳細については、 『 JMX を使用した Liberty への接続 』を参照してください。

アプリケーションの許可

次の図は、アプリケーションに対して許可がどのように行われるかを示しています。 許可サービスは、アプリケーションおよびサーバーの構成ファイルでユーザーへのロールのマッピングを検査してから、アクセス要求を認可または拒否します。

この図に示しているように、Web コンテナーは許可サービスに接続します。この許可サービスは ibm-application-bnd.xml/xmi ファイルと server.xml ファイルを検査してセキュリティー・ロールを判別します。 その後、許可サービスは、これらのロールを許可テーブルと照合してから、応答を Web コンテナーに送信します。

1. エンティティーが、 Libertyによって提供されるアプリケーション内のリソースにアクセスしようとすると、許可が行われます。 Web コンテナーは、許可サービスを呼び出して、 1 つ以上の一連の必要なロールがある中で、特定リソースにアクセスする権限がユーザーにあるかどうかを判別します。 必要なロールは、デプロイメント記述子の auth-constraint エレメント、および @ServletSecurity アノテーションによって決定されます。
2. 許可サービスでは、必要なロールがマップされるオブジェクトを決定します。 このステップは、 ibm-application-bnd.xmi ファイルまたは ibm-application-bnd.xml ファイルで定義されたマッピング、および server.xml ファイルの application-bnd エレメントを処理することによって実行されます。 これら 2 つのソースのマッピングはマージされます。 両者のソースに同じロールがある場合には、 server.xml ファイルのロール・マッピングだけが使用されます。 ロールとユーザーのマッピングに server.xml ファイルを使用すると、利点として、 アプリケーションを EAR ファイルにパッケージ化する必要がなくなり、更新が簡単になります。 あるいは、 ibm-application-bnd.xmi/xml ファイルを使用すると、 server.xml ファイルをサポートしない他のサーバーや他の WebSphere® Application Server traditional サーバーにアプリケーションを移植することができます。
3. 必要なロールが特別な対象の EVERYONE にマップされている場合、 許可サービスは、即時に戻ってすべてのユーザーのアクセスを許可します。 ロールが特別な対象の ALL_AUTHENTICATED_USERS にマップされ、そのユーザーが認証済みである場合、許可サービスは、そのユーザーにアクセスを許可します。 これらのいずれの条件も満たされない場合、 許可サービスは、必要なロールにどんなユーザーおよびグループがマップされているかを判別します。 必要なロールにユーザーがマップされている場合、または必要なロールにマップされているグループにユーザーが所属している場合、 許可サービスはリソースへのアクセスを許可します。
4. 許可サービスは、ユーザーがアクセスを許可されたか、拒否されたかを示す結果を Web コンテナーに返します。

特別な対象

エンティティーをロールにマップする際に、特定のユーザーまたはグループではなく、 特別な対象をマップすることができます。 特別な対象は、対象の概念を拡張したものです。 特別な対象により、特定のカテゴリーに入るユーザーのグループを表すことができます。

    <application-bnd>
           <security-role name="AllAuthenticated">
               <special-subject type="ALL_AUTHENTICATED_USERS" />
           </security-role>
       </application-bnd>

Libertyでのアプリケーションの許可の構成を参照してください。

アクセス ID と許可

ユーザーまたはグループを許可する際には、そのユーザーまたはグループを一意的に識別する方法がサーバーに必要になります。 ユーザーおよびグループの固有 ID は、この目的を果たすものとして、許可構成の構築に使用されます。 これらの ID は、ユーザー・レジストリー実装によって決定されます。固有ユーザー ID は getUniqueUserId() の値で、固有グループ ID は getUniqueGroupId() の値です。 また、許可構成でユーザーまたはグループのアクセス ID を明示的に指定することもできます。 ユーザー・レジストリー実装で返される値の代わりに、これらの明示的なアクセス ID が使用されます。 ibm-application-bnd.xml/xmi ファイルまたは server.xml ファイル ( application-bnd は application エレメントの下にあります) でアクセス ID を指定するには、 user エレメントまたは group エレメントの access-id 属性を使用します。

    <application-bnd>
           <security-role name="Employee">
               <user name="Bob" access-id="user:MyRealm/Bob"/>
               <group name="developers" access-id="group:myRealm/developers"/>
           </security-role>
    </application-bnd>

OAuth

OAuth は、委任された許可のオープン・スタンダードです。 OAuth 許可フレームワークにより、ユーザーは、アクセス許可やデータのフルエクステントを共有することなく、別の HTTP サービスで保管された情報へのアクセス権限をサード・パーティー・アプリケーションに付与できます。 Liberty での認証に OAuth を使用する方法の詳細については、『 OAuth 』のドキュメントを参照してください。

ロール・マッピング・バインディングが提供されていない場合のアプリケーションの許可

<application type="war" id="myapp" name="myapp" 	location="${server.config.dir}/apps/myapp.war">
      <application-bnd>
	     <security-role name="anyAppRoleName"/>
      </application-bnd>
</application>