<commit_before>== Spring Data REST + Spring Security

This example shows how to secure a http://projects.spring.io/spring-data-rest[Spring Data REST] application in multiple ways with http://projects.spring.io/spring-security[Spring Security].

=== Defining the domain

For a basic Spring Data REST application, we need to define some domain objects. In this case, we have a company. The company has both employees and items it manages. The domain objects are declared as POJOs with JPA annotations.

.src/main/java/example/company/Employee.java
====
[source,java]
----
@Entity
public class Employee {

  private @Id @GeneratedValue Long id;
  private String firstName;
  private String lastName;
  private String title;

  …
}
----
====

.src/main/java/example/company/Item.java
====
[source,java]
----
@Entity
public class Item {

  private @Id @GeneratedValue Long id;
  private String description;

  …
}
----
====

=== Defining the repositories

Spring Data is based on the repository paradigm. In this case, we are defining a repository for each of these domain objects.

.src/main/java/example/company/EmployeeRepository.java
====
[source,java]
----
public interface EmployeeRepository extends CrudRepository<Employee, Long> {}
----
====

`EmployeeRepository` is about as simple as things can get. It extends Spring Data Commons' `CrudRepository`. This means that the repo doesn't HAVE to be tied to JPA. If the underlying `Employee` object was retooled for MongoDB, this repository definition would require no changes.

Now let's look at the next repository:

.src/main/java/example/company/ItemRepository.java
====
[source,java]
----
@PreAuthorize("hasRole('ROLE_USER')")
public interface ItemRepository extends CrudRepository<Item, Long>  {

  @PreAuthorize("hasRole('ROLE_ADMIN')")
  @Override
  Item save(Item s);

  @PreAuthorize("hasRole('ROLE_ADMIN')")
  @Override
  void delete(Long aLong);
}
----
====

This repository is simple in its functionality, but it has been marked up with Spring Security annotations (`@PreAuthorize`). The repository at the top level requires that the user have *ROLE_USER* before ANYTHING is granted.

NOTE: These code examples use Spring Security's more modern http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#method-security-expressions[]@PreAuthorize] annotations. But you can also use http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#enableglobalmethodsecurity[@Secured] or JSR-250's security annotations. (Be advised, that JSR-250 annotations do NOT work at the interface level.)

To fine tune security policies, `save(Item)` and `delete(Item)` are overrides of `CrudRepository`, allowing us to further restrict these operations to require **ROLE_ADMIN*.

NOTE: This issue was fixed in 3.2.6, but hasn't been published yet as an artifact for consumption. Spring Security 4.0.0.CI-SNAPSHOT does have the fix in place.

=== Writing a security policy

The final bit that is needed is a security policy. By default, when using Spring Boot, everything is locked down and a random password is generated. Usually, you will want to replace this with a user store of some kind. In addition to that, you need to configure method-level security. To top it off, it is also possible to secure Spring Data REST endpoints at the URL level. All of this is shown below:

.src/main/java/example/company/SecurityConfiguration.java
====
[source,java]
----
@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

  /**<commit_msg>#23 - Fixed typo and styling in security example.<commit_after>== Spring Data REST + Spring Security

This example shows how to secure a http://projects.spring.io/spring-data-rest[Spring Data REST] application in multiple ways with http://projects.spring.io/spring-security[Spring Security].

=== Defining the domain

For a basic Spring Data REST application, we need to define some domain objects. In this case, we have a company. The company has both employees and items it manages. The domain objects are declared as POJOs with JPA annotations.

.src/main/java/example/company/Employee.java
====
[source,java]
----
@Entity
public class Employee {

  private @Id @GeneratedValue Long id;
  private String firstName;
  private String lastName;
  private String title;

  …
}
----
====

.src/main/java/example/company/Item.java
====
[source,java]
----
@Entity
public class Item {

  private @Id @GeneratedValue Long id;
  private String description;

  …
}
----
====

=== Defining the repositories

Spring Data is based on the repository paradigm. In this case, we are defining a repository for each of these domain objects.

.src/main/java/example/company/EmployeeRepository.java
====
[source,java]
----
public interface EmployeeRepository extends CrudRepository<Employee, Long> {}
----
====

`EmployeeRepository` is about as simple as things can get. It extends Spring Data Commons' `CrudRepository`. This means that the repo doesn't HAVE to be tied to JPA. If the underlying `Employee` object was retooled for MongoDB, this repository definition would require no changes.

Now let's look at the next repository:

.src/main/java/example/company/ItemRepository.java
====
[source,java]
----
@PreAuthorize("hasRole('ROLE_USER')")
public interface ItemRepository extends CrudRepository<Item, Long>  {

  @PreAuthorize("hasRole('ROLE_ADMIN')")
  @Override
  Item save(Item s);

  @PreAuthorize("hasRole('ROLE_ADMIN')")
  @Override
  void delete(Long aLong);
}
----
====

This repository is simple in its functionality, but it has been marked up with Spring Security annotations (`@PreAuthorize`). The repository at the top level requires that the user have *ROLE_USER* before ANYTHING is granted.

NOTE: These code examples use Spring Security's more modern http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#method-security-expressions[@PreAuthorize] annotations. But you can also use http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#enableglobalmethodsecurity[@Secured] or JSR-250's security annotations. (Be advised, that JSR-250 annotations do NOT work at the interface level.)

To fine tune security policies, `save(Item)` and `delete(Item)` are overrides of `CrudRepository`, allowing us to further restrict these operations to require *ROLE_ADMIN*.

NOTE: This issue was fixed in 3.2.6, but hasn't been published yet as an artifact for consumption. Spring Security 4.0.0.CI-SNAPSHOT does have the fix in place.

=== Writing a security policy

The final bit that is needed is a security policy. By default, when using Spring Boot, everything is locked down and a random password is generated. Usually, you will want to replace this with a user store of some kind. In addition to that, you need to configure method-level security. To top it off, it is also possible to secure Spring Data REST endpoints at the URL level. All of this is shown below:

.src/main/java/example/company/SecurityConfiguration.java
====
[source,java]
----
@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

  /**
{'fraction_non_alphanumeric': 0.09684995855208621, 'fraction_numerical': 0.003592152528322741, 'mean_word_length': 4.624708624708624, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6479633', 'n_tokens_mistral': 1991, 'n_tokens_neox': 1899, 'n_words': 821}