Spring Security Concepts

Internal

• Spring Security

Spring Boot and Security

Spring Security is enabled by the following Spring Boot starter dependency:

dependencies {

    implementation('org.springframework.boot:spring-boot-starter-security')
}

Spring Boot autoconfiguration will detect that Spring Security artifacts are in the class path and for a web application, basic security will be enabled:

• All HTTP request paths require authentication.
• No specific roles or authorities are required.
• There is only one user, with the user name of user. The password is generated and displayed in the boot logs:

Using generated security password: a18ff68c-bdc1-4990-933e-6bdf896e2b72

Security Configuration

Security can be configured

• via XML
• via Java-based configuration

User Store

The user store can be configured overriding the configure(AuthenticationManagerBuilder) method defined in WebSecurityConfigurerAdapter.

In-Memory User Store

A user store appropriate for the situation when there is a small, static set of users, which can be defined as part of the security configuration. This method is convenient for testing purposes, but if you need to add, remove or update users, the application has to be rebuilt and redeployed.

In-Memory User Store Example

JDBC-based User Store

A user store where user information is maintained in a relational database, in a set of tables that are not part of the application domain model. JDBC-based user store assumes a set of default tables, but the table names and the queries can be also customized. Spring also provides integration support for the situation when user information is part of the application's domain model.

JDBC-basedUser Store Example

Default Tables

Without additional configuration, the JDBC-based used store assumes there is a "USERS" table from which the username, password and the boolean flag indicating whether a user is enabled or not can be obtained with the following query:

SELECT USERNAME, PASSWORD, ENABLED FROM USERS WHERE USERNAME = ?

This query is used to authenticate the user.

The JDBC-based user store also assumes the existence of an "AUTHORITIES" table from which the authorities of a user can be obtained with the following query, for authorization purposes:

SELECT USERNAME, AUTHORITY FROM AUTHORITIES WHERE USERNAME = ?

Finally, it assumes the existence of tables "GROUPS", "GROUP_MEMBERS" and "GROUP_AUTHORITIES" from which group information and group-associated authorities can be obtained with the following query, also for authorization purposes:

SELECT G.ID, G.GROUP_NAME, GA.AUTHORITY 
FROM GROUPS G, GROUP_MEMBERS GM, GROUP_AUTHORITIES GA 
WHERE GM.USERNAME = ? AND G.ID = GA.GROUP_ID AND G.ID = GM.GROUP_ID

The H2 DDL that creates conforming tables is available here.

Custom Tables

JDBC-based User Store can be configured to use custom tables, by configuring custom "users by name", "authorities by username" and "group authorities by username" queries (SIA page 90). The basic contract is that all take the user name as the only parameter. The authentication query selects the username, password and enabled status. The authorities query selects zero or more rows containing the username and a granted authority. The group authorities query selects zero or more rows, each with a group ID, a group name and an authority.

LDAP-Backed User Store

SIA page 92.

User Stores and Password Encoder

A password encoder must be specified. It seems that if we don't configure any password encoder on the user store, we get:

java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the id ...

As a quick workaround, not recommended for production, configure the store with a NoOpPasswordEncoder:

auth.[...]Authentication()[...].passwordEncoder(NoOpPasswordEncoder.getInstance());

Alternatively, prefix the password values with "{noop}"

The password encoder must implement the PasswordEncoder interface. Several implementations are available: BCryptPasswordEncoder, NoOpPasswordEncoder, Pbkdf2PasswordEncoder, SCryptPasswordEncoder, StandardPasswordEncoder. Regardless of the password encoder in use, the password in the database is never decoded. Rather, the password that comes over wire is encoded and compared with the encoded form stored in the database. IF those representations match, authentication is successful. The matching is performed by PasswordEncoder.matches(CharSequence rawPassword, String encodedPassword).