アノテーションを使用した JAX-RS 2.0 リソースの保護
セキュリティー設定を指定するアノテーションを使用して、 Java™ API for RESTful Web Services (JAX-RS) リソースを保護できます。
始める前に
このタスクは、アプリケーションが開発済みで、セキュリティーに関するアノテーションを使用して保護する JAX-RS リソースが特定されていることを前提としています。
このタスクについて
- @PermitAll
- すべてのセキュリティー・ロールに対して JAX-RS リソースへのアクセスを許可することを指定します。
- @DenyAll
- どのセキュリティー・ロールに対しても JAX-RS リソースへのアクセスを許可しないことを指定します。
- @RolesAllowed
- JAX-RS リソースへのアクセスが許可されるセキュリティー・ロールを指定します。
クラス・レベルでアノテーションを付けるか、またはメソッド・レベルでアノテーションを付けるかを選択できます。以下のルールにより、セキュリティー用のアノテーションは制御されます。
- メソッド・レベルのアノテーションが、クラス・レベルのアノテーションよりも優先されます。
- 以下のコード・スニペットでは、/addresses の @GET アノテーションと @Path アノテーション、および対応する getList() メソッドによって参照されている JAX-RS リソースが制限されておらず、パブリック使用のために公開されています。ただし、/addresses の @PUT アノテーションと @Path アノテーションおよび対応する updateList() メソッドで参照されているリソースでは、Manager ロールが必要です。例:
@Path(value="/addresses") @PermitAll public class AddressBookResource { @GET @Produces(value="text/plain") public String getList() { } @PUT @RolesAllowed(“Manager”) public void updateList(String[] books) { } }
- セキュリティーに関するアノテーションは互いに排他的です。
- これは、各リソースが、最大で 1 つのセキュリティー用アノテーションによってのみ制御されることを意味します。例えば、@PermitAll と @RolesAllowed の両方が指定されているため、以下の例は無効です。
@Path(value="/addresses") @PermitAll @RolesAllowed(“Employee”) public class AddressBookResource { @GET @Produces(value="text/plain") public String getList() { } }
上記のコード例では、@RolesAllowed アノテーションが優先され、@PermitAll アノテーションは無視されます。 同様に、@DenyAll と @RolesAllowed の両方のアノテーションが指定されていると、@DenyAll アノテーションが優先されます。
同じように、メソッド・レベルで、またはクラス・レベルで @PermitAll と @DenyAll の両方のアノテーションが指定されている場合、安全なデフォルトの原則に従うことでセキュリティーを確保する@DenyAll アノテーションが優先されます。
メソッド・レベルまたはクラス・レベルで @PermitAll、@DenyAll、および @RolesAllowed の各アノテーションがすべて存在している場合、@DenyAll アノテーションが @RolesAllowed および @PermitAll よりも優先されます。以下のリストは、これらのアノテーションの優先順位の順序を示しています。- @DenyAll
- @RolesAllowed
- @PermitAll
- 継承のルール
- クラス・レベルで追加されている JSR 250 アノテーションは、アノテーション対象のクラスおよびサブリソースの対応するメソッドにのみ影響します。 クラス・レベルで指定されているアノテーションは、スーパークラスから継承されているリソースには影響しません。
- メソッドのオーバーライドのルール
- サブクラスでオーバーライドされたメソッドに対応しているリソースでのアノテーションは、親クラスに含まれているアノテーションよりも優先されます。以下のスニペットでは、LocalAdministrator ロールを使用して /addresses/local サブリソースにアクセスしています。例:
@Path(value="/addresses") @PermitAll public class AddressBookResource { @GET @Produces(value="text/plain") public String getList() { } @PUT @RolesAllowed(“Administrator”) public void updateList(String books) { } } @Path(value="/addresses") @PermitAll public class LocalAddressBookResource extends AddressBookResource { @PUT @RolesAllowed(“LocalAdministrator”) @Path(value=”local”) public void updateList(String books){ } }
- @RolesAllowed の考慮事項
- 1 つのリソース上に同時に複数の @RolesAllowed アノテーションを持つことはできません。例えば、以下を実現する場合を考えます。
この場合、以下のコード・スニペットを使用します。@RolesAllowed("role1") @RolesAllowed("role2") public String foo() { }
@RolesAllowed({"role1", "role2"}) public String foo() { }
- セキュリティーに関するアノテーションの使用およびセキュリティー制約の構成に関する考慮事項
-
セキュリティーに関するアノテーションは、宣言セキュリティー・モデルに従います。デプロイメント記述子 (web.xml ファイル) で構成されているセキュリティー制約は、アプリケーションにおいてプログラムでアノテーションにより設定されているセキュリティー制約に優先します。JAX-RS リソースの開発者が、構成可能なセキュリティー制約とアノテーションによるセキュリティー制約の間でのバランスを考慮することが重要になります。アノテーションによる制約は、構成されているセキュリティー制約に追加されるものです。JAX-RS ランタイム環境は、Web コンテナー・ランタイム環境が web.xml ファイル内に構成されているセキュリティー制約を検査した後、アノテーションによる制約を検査します。
web.xml ファイル内で認証の制約を構成します。以下の web.xml ファイルの例では、SecurityConstraint_1 セキュリティー制約が定義されています。この制約は、アプリケーションへの認証を要求するために使用されます。また、SecurityConstraint_1 セキュリティー制約は、JAX-RS リソースに対応する URL パターンに関する制約を定義します。これらの制約のいずれかに対応する JAX-RS リソースにアクセスすると、許可検査が行われます。構成されている制約が検証されてからはじめて、宣言セキュリティー・アノテーションのアクセス検査が実行されます。<web-app id="WebApp_someID"> <servlet> <servlet-name>AddressBookAppSample</servlet-name> <servlet-class> com.ibm.websphere.jaxrs.server.IBMRestServlet </servlet-class> <init-param> <param-name>javax.ws.rs.Application</param-name> <param-value>jaxrs.sample.AddressBookApplication</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>AddressBookApp</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> <security-constraint id="SecurityConstraint_1"> <web-resource-collection id="WebResourceCollection_1"> <web-resource-name>AddressBookAppSample</web-resource-name> <description>Protection area for Rest Servlet</description> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> <http-method>PUT</http-method> </web-resource-collection> <auth-constraint id="AuthConstraint_1"> <description>Role1 for this rest servlet</description> <role-name>Role</role-name> </auth-constraint> <user-data-constraint id="UserDataConstraint_1"> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <security-role id="SecurityRole_1"> <description>This Role is used to drive authentication</description> <role-name>Role1</role-name> </security-role> <login-config> <auth-method>BASIC</auth-method> <realm-name>test realm</realm-name> </login-config> </web-app>
上記のサンプル web.xml ファイルでは、Role1 がアプリケーション全体に使用されます。宣言セキュリティー・アノテーションのみを定義し、web.xml ファイルの許可制約を使用しない場合、ユーザー認証用の AllAuthenticated 特殊サブジェクトに JAX-RS アプリケーションに対するこのロールをマップすることができます。
手順
- ご使用の JAX-RS アプリケーションの web.xml ファイルで定義されているセキュリティー制約がないかを確認します。
- web.xml ファイルを構成して、セキュリティー制約を追加します。 デプロイメント記述子である web.xml ファイルで構成されているセキュリティー制約は、アプリケーションでプログラマチックにアノテーション付けされるセキュリティー制約よりも優先されます。
- web.xml ファイル内のすべての制約に加えて、セキュリティーに関するアノテーションを追加するかどうかを決定します。 JAX-RS リソースに追加のセキュリティーを提供するために、@PermitAll、@DenyAll、および @RolesAllowed のいずれかのアノテーションを追加するかどうかを決定します。前述の優先順位や継承などの、セキュリティーに関するアノテーションを追加する場合のルールを考慮してください。
タスクの結果
宣言セキュリティー・アノテーションを使用して、セキュアな JAX-RS リソースを定義しました。
例
@Path(value="/addresses")
@PermitAll
public class AddressBookResource {
@GET
@Produces(value="text/plain")
public String getList() {
}
@RolesAllowed(“Administrator”)
@PUT
public void updateList(String books) {
}
}