セキュリティ

Spring Data REST は Spring Security と非常にうまく連携します。このセクションでは、メソッドレベルのセキュリティで Spring Data REST サービスを保護する方法の例を示します。

@Pre および @Post セキュリティ

Spring Data REST のテストスイートからの次の例は、Spring Security の PreAuthorization モデル (最も洗練されたセキュリティモデル) を示しています。

例 1: spring-data-rest-tests/spring-data-rest-tests-security/src/test/java/org/springframework/data/rest/tests/security/PreAuthorizedOrderRepository.java
@PreAuthorize("hasRole('ROLE_USER')") (1)
public interface PreAuthorizedOrderRepository extends CrudRepository<Order, UUID> {

	@PreAuthorize("hasRole('ROLE_ADMIN')")
	@Override
	Optional<Order> findById(UUID id);

	@PreAuthorize("hasRole('ROLE_ADMIN')") (2)
	@Override
	void deleteById(UUID aLong);

	@PreAuthorize("hasRole('ROLE_ADMIN')")
	@Override
	void delete(Order order);

	@PreAuthorize("hasRole('ROLE_ADMIN')")
	@Override
	void deleteAll(Iterable<? extends Order> orders);

	@PreAuthorize("hasRole('ROLE_ADMIN')")
	@Override
	void deleteAll();
}
1 この Spring Security アノテーションは、リポジトリ全体を保護します。Spring Security SpEL 式は、プリンシパルがロールのコレクションに ROLE_USER を持っている必要があることを示します。
2 メソッドレベルの設定を変更するには、メソッドシグネチャーをオーバーライドし、Spring Security アノテーションを適用する必要があります。この場合、このメソッドは、ユーザーが削除を実行するための ROLE_ADMIN を持っているという要件で、リポジトリレベルの設定をオーバーライドします。

前の例は、いくつかの重要な変更を加えて CrudRepository を継承する標準の Spring Data リポジトリ定義を示しています。さまざまなメソッドにアクセスするための特定のロールの仕様:

リポジトリとメソッドレベルのセキュリティ設定は組み合わされません。代わりに、メソッドレベルの設定がリポジトリレベルの設定を上書きします。

前の例は、CrudRepository には実際には 4 つの削除メソッドがあることを示しています。適切に保護するには、すべての削除メソッドをオーバーライドする必要があります。

@Secured セキュリティ

次の例は、Spring Security の古い @Secured アノテーションを示しています。これは、純粋にロールベースです。

例 2: spring-data-rest-tests/spring-data-rest-tests-security/src/test/java/org/springframework/data/rest/tests/security/SecuredPersonRepository.java
@Secured("ROLE_USER") (1)
@RepositoryRestResource(collectionResourceRel = "people", path = "people")
public interface SecuredPersonRepository extends CrudRepository<Person, UUID> {

	@Secured("ROLE_ADMIN") (2)
	@Override
	void deleteById(UUID aLong);

	@Secured("ROLE_ADMIN")
	@Override
	void delete(Person person);

	@Secured("ROLE_ADMIN")
	@Override
	void deleteAll(Iterable<? extends Person> persons);

	@Secured("ROLE_ADMIN")
	@Override
	void deleteAll();
}
1 これにより、前の例と同じセキュリティチェックが行われますが、柔軟性は低くなります。アクセスを制限する手段としてのロールのみを許可します。
2 繰り返しますが、これは削除メソッドが ROLE_ADMIN を必要とすることを示しています。
新しいプロジェクトから始める場合、または最初に Spring Security を適用する場合は、@PreAuthorize が推奨されるソリューションです。アプリの他の部分で Spring Security と @Secured をすでに使用している場合は、すべてを書き直すことなく、そのパスを続行できます。

メソッドレベルのセキュリティの有効化

メソッドレベルのセキュリティを構成するために、Spring Data REST のテストスイートからの短いスニペットを次に示します。

例 3: spring-data-rest-tests/spring-data-rest-tests-security/src/test/java/org/springframework/data/rest/tests/security/SecurityConfiguration.java
@Configuration (1)
@EnableWebSecurity
@EnableMethodSecurity(securedEnabled = true, prePostEnabled = true) (2)
class SecurityConfiguration { (3)
	...
}
1 これは Spring 構成クラスです。
2Spring Security の @EnableGlobalMethodSecurity アノテーションを使用して、@Secured と @Pre/@Post の両方のサポートを有効にします。注: 両方を使用する必要はありません。この特定のケースは、両方のバージョンが Spring Data REST で動作することを証明するために使用されます。
3 このクラスは、セキュリティの純粋な Java 構成に使用される Spring Security の WebSecurityConfigurerAdapter を継承します。

残りの構成クラスは、Spring Security リファレンスドキュメントで読むことができる標準的な方法に従っているため、リストされていません。