Liberty: 許可
Liberty の許可では、システム内の特定のロールにユーザーがアクセスできるかどうかを決定します。
許可はリソースに対するアクセス権限を指定します。通常、ID を確認する認証の後に行われます。認証は「本当に自称しているユーザーであるか」という問いに答えるのに対し、 許可は「実行しようとしている内容を行う権限があるか」という問いに答えるものです。
管理機能の許可
エンティティーがリソースにアクセスしようとすると、 リソースへのアクセスに必要な権限がそのエンティティーにあるかどうかを許可サービスが判断します。 この概念は、エンティティーがアプリケーションにアクセスする場合でも、管理機能を実行する場合でも同じです。 アプリケーションへのアクセスの許可と、管理機能へのアクセスの許可における主な違いは、ユーザーがどのようにロールにマップされるかという点にあります。 アプリケーションの許可では、server.xml ファイルの application-bnd エレメント、または ibm-application-bnd.xml/xmi ファイルを使用して、ユーザーをロールにマップします。管理機能の許可では、server.xml ファイルの administrator-role エレメントを使用して、ユーザーを管理者ロールにマップします。管理セキュリティーについて詳しくは、『JMX を使用した Liberty への接続』を参照してください。
アプリケーションの許可
次の図は、 アプリケーションに対して許可がどのように行われるかを示しています。

- Liberty によって処理されているアプリケーションでエンティティーがリソースにアクセスしようとすると、許可が行われます。Web コンテナーは、許可サービスを呼び出して、 1 つ以上の一連の必要なロールがある中で、特定リソースにアクセスする権限がユーザーにあるかどうかを判別します。 必要なロールは、デプロイメント記述子の auth-constraint エレメント、および @ServletSecurity アノテーションによって決定されます。
- 許可サービスでは、必要なロールがマップされるオブジェクトを決定します。 このステップは、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・サーバーにアプリケーションを移植できるようになります。
- 必要なロールが特別な対象の EVERYONE にマップされている場合、 許可サービスは、即時に戻ってすべてのユーザーのアクセスを許可します。 ロールが特別な対象の ALL_AUTHENTICATED_USERS にマップされ、そのユーザーが認証済みである場合、許可サービスは、そのユーザーにアクセスを許可します。これらのいずれの条件も満たされない場合、 許可サービスは、必要なロールにどんなユーザーおよびグループがマップされているかを判別します。 必要なロールにユーザーがマップされている場合、または必要なロールにマップされているグループにユーザーが所属している場合、 許可サービスはリソースへのアクセスを許可します。
- 許可サービスは、ユーザーがアクセスを許可されたか、拒否されたかを示す結果を Web コンテナーに返します。
特別な対象
エンティティーをロールにマップする際に、特定のユーザーまたはグループではなく、 特別な対象をマップすることができます。 特別な対象は、対象の概念を拡張したものです。 特別な対象により、特定のカテゴリーに入るユーザーのグループを表すことができます。
- EVERYONE: システム上のすべてのエンティティーを表します。 つまり、全員がアクセスを許可され、クレデンシャルの入力を求められないため、セキュリティーが使用可能ではないことになります。
- ALL_AUTHENTICATED_USERS: サーバーに対して認証が成功したすべてのエンティティーを表します。
<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>