AutoRentals Assignment 3: Security

activate Spring Security

create multiple, custom authentication filter chains

enable open access to static resources

enable anonymous access to certain URIs

enforce authenticated access to certain URIs

Turn off CSRF protections.

Add a static text file past_transactions.txt that will be made available below the /content/ URI. Place the following title in the first line so that the following will be made available from a web client.

$ curl -X GET http://localhost:8080/content/past_transactions.txt
Past AutoRentals

Configure anonymous access for the following resources methods

Configure authenticated access for the following resource operations

Create a unit integration test case that verifies (provided)

Restrict this security configuration to the anonymous-access profile and activate that profile while testing this section.

activate Spring Security

create multiple, custom authentication filter chains

enable open access to static resources

enable anonymous access to certain URIs

enforce authenticated access to certain URIs

No accounts are necessary for this portion of the assignment. All testing is performed using an anonymous caller.

Turning on TRACE for Spring Web Security may provide helpful narrative to actions taken

logging.level.org.springframework.security.web=TRACE

Setting a breakpoints at or near:

add an authenticated identity to RestTemplate, or RestClient client

locate the current authenticated user identity

Configure the application to use a test username/password of ted/secret during testing with the authenticated-access profile.

spring.security.user.name: ...
spring.security.user.password: ...

@SpringBootTest(...)
@ActiveProfiles({"test", "authenticated-access"})

@Value("${spring.security.user.name:}") (1)
private String username;
@Value("${spring.security.user.password:}")
private String password;

Configure the application to support BASIC authentication.

Turn off CSRF protections.

Turn off sessions, and any other filters that prevent API interaction beyond authentication.

Add a new resource api/whoAmI (provided)

Create a set of unit integration tests that demonstrate the following (provided):

Restrict this security configuration to the authenticated-access profile and activate that profile during testing this section.

@Configuration(proxyBeanMethods = false)
@Profile({"authenticated-access", "userdetails"}) (1)
public class PartA2_AuthenticatedAccess {
===
@SpringBootTest(classes={...},
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ActiveProfiles({"test", "authenticated-access"}) (2)
public class MyA2_AuthenticatedAccessNTest extends A2_AuthenticatedAccessNTest {

Establish a security configuration that is active for the nosecurity profile which allows for but does not require authentication to call each resource/method. This will be helpful to simplify some demonstration scenarios where security is not essential.

@Configuration(proxyBeanMethods = false)
@Profile("nosecurity") (1)
public class PartA2b_NoSecurity {
===
@SpringBootTest(classes= { ...
@ActiveProfiles({"test", "nosecurity"}) (1)
public class MyA2b_NoSecurityNTest extends A2b_NoSecurityNTest {

curl -X POST http://localhost:8080/api/autos -H 'Content-Type: application/json' -d '{ ... }'
{ ... }

add an authenticated identity to RestTemplate or RestClient client

locate the current authenticated user identity

build a UserDetailsService implementation to host user accounts and be used as a source for authenticating users

build an injectable UserDetailsService

encode passwords

mary/secret

lou/secret

murry/secret

ted/secret

sueann/betty

Create a UserDetailsService that is activated during the userdetails profile.

Create a unit integration test case that (provided):

build a UserDetailsService implementation to host user accounts and be used as a source for authenticating users

build an injectable UserDetailsService

encode passwords

There is no explicit requirement that the UserDetailsService be implemented using a database. If you do use a database, use an in-memory RDBMS so that there are no external resources required.

You may use a DelegatingPasswordEncoder to satisfy the BCrypt encoding requirements, but the value stored must be in BCrypt form.

The implementation choice for PasswordEncoder and UserDetailsService is separate from one another and can be made in separate @Bean factories.

@Bean
public PasswordEncoder passwordEncoder() {...}
@Bean
public UserDetailsService userDetailsService(PasswordEncoder encoder, ...) {...}

The commonality of tests differentiated by different account properties is made simpler with the use of JUnit @ParameterizedTest. However, by default method sources are required to be declared as Java static methods — unable to directly reference beans injected into non-static attributes. @TestInstance(TestInstance.Lifecycle.PER_CLASS) can be used to allow the method source to be declared a Java non-static method and directly reference the injected Spring context resources.

You may annotate a @Test or @Nested testcase class with @DirtiesContext to indicate that the test makes changes that can impact other tests and the Spring context should be rebuilt after finishing.

define role-based and permission-based authorities

mary: ROLE_ADMIN, ROLE_MEMBER

lou: ROLE_MGR (no role member)

murry: ROLE_MEMBER, PROXY

ted: ROLE_MEMBER

sueann: ROLE_MEMBER

Create an api/authorities resource with a GET method (provided):

Create a UserDetailsService that is active during the authorities profile.

Create one or more unit integration test cases that (provided):

define role-based and permission-based authorities

There is no explicit requirement to use a database for the user details in this assignment. However, if you do use an database, please use an in-memory RDBMS instance so there are no external resources required.

The repeated tests due to different account data can be simplified using a @ParameterizedTest. However, you will need to make use of @TestInstance(TestInstance.Lifecycle.PER_CLASS) in order to leverage the Spring context in the @MethodSource.

implement URI path-based authorization constraints

implement annotation-based authorization constraints

implement role inheritance

implement an AccessDeniedException controller advice to hide necessary stack trace information and provide useful error information to the caller

Update the resources to store the identity of the caller with the resource created to identify the owner

Define access constraints for resources using path and expression-based authorizations. Specific authorization restriction details are in the next requirement.

Restrict access according to the following

Form the following role inheritance

Implement a mechanism to hide stack trace or other details from the API caller response when an AccessDeniedException occurs. From this point forward — stack traces can be logged on the server-side but should not be exposed in the error payload.

Create unit integration test(s) to demonstrate the behavior defined above

implement URI path-based authorization constraints

implement annotation-based authorization constraints

implement role inheritance

implement an AccessDeniedException controller advice to hide necessary stack trace information and provide useful error information to the caller

Role inheritance can be defined using a RoleHierarchy bean.

With the requirements for fine-grain authority checks, the amount of additional declarative path-based and annotation-based access checking will still be present, but minimal. If a user and users with special authorizations can perform the same action, it will be understandable for declarative checks enforce authenticated and programmatic checks for special authority conditions.

An optional AuthorizationHelper has been provided and demonstrated in the Auto and Renter security wrappers. It has get()/has() inspection methods that simply return information from the SecurityContext. It also has assert() methods that throw AccessDeniedException for anything that fails. You may use it or implement your own inspection/assertion mechanisms if it does not meet your needs.

generate a self-signed certificate for demonstration use

enable HTTPS/TLS within Spring Boot

implement an integration unit test using HTTPS

Implement an HTTPS-only communication in the server when running with the https profile.

Implement a unit integration test that will

generate a self-signed certificate for demonstration use

enable HTTPS/TLS within Spring Boot

There is no requirement to implement an HTTP to HTTPS redirect

See the svc/svc-security/https-hello-example for Maven and RestTemplate setup example.

Implement the end-to-end integration test with HTTP before switching to HTTPS to limit making too many concurrent changes.

obtain a method reference and invoke it using Java Reflection

implement the getGetterMethod() to locate and return the java.lang.reflect.Method for the requested (getter) method name.

implement the getValue() method to return the value reported by invoking the getter method using reflection

use the supplied JUnit unit tests to validate your solution. There is no Spring context required/used for this test.

obtain a method reference and invoke it using Java Reflection

The JUnit test (MyD1_ReflectionMethodTest) is supplied and should not need to be modified beyond enabling it.

The tests will feed your solution with DTO instances in various valid and invalid states according to the isNull and notNull calls. There will also be some non-DTO classes used to verify the logic is suitable for generic parameter types.

create a JDK Dynamic Proxy to implement adhoc interface(s) to form a proxy at runtime for implementing advice

implement the details for the NullValidatorHandler class that

Use the provided JUnit tests (MyD2_DynamnicProxyNTest) verify the functionality of the requirements above once you activate.

create a JDK Dynamic Proxy to implement adhoc interface(s) to form a proxy at runtime for implementing advice

The JUnit test case uses real AutoService and RenterService @Autowired from the Spring context, but only instantiates the proxy as a POJO within the test case.

The JUnit tests make calls to the AutoService and RenterService, passing valid and invalid instances according to how your proxy was instantiated during the call to newInstance().

The completed dynamic proxy will not be used beyond this section of the assignment. However, try to spot what the dynamic proxy has in common with the follow-on Aspect solution — since Spring interface Aspects are implemented using Dynamic Proxies.

implement dynamically assigned behavior to methods using Spring Aspect-Oriented Programming (AOP) and AspectJ

identify method join points to inject using pointcut expressions

implement advice that executes before join points

implement parameter injection into advice

add AOP dependencies using the spring-boot-starter-aop module (provided)

enable AspectJ auto proxy handling within your application

create a ValidatorAspect component. The shell of a class and @Bean factory have been provided.

define a "pointcut" that will target the calls to the SecureAutosWrapper and SecureRentersWrapper services. This pointcut should both:

define an "advice" method to execute before the "join point"

Use the provided JUnit test cases to verify completion of the above requirements

implement dynamically assigned behavior to methods using Spring Aspect-Oriented Programming (AOP) and AspectJ

identify method join points to inject using pointcut expressions

implement advice that executes before join points

implement parameter injection into advice

You are to base your AOP validation based on the data found within the injected List<MethodConstraints>. Each instance contains the name of the method and a list of property names that should be subject to isNull or notNull assertions.

aop:
  validation:
    - methodName: createAuto
      isNull: [id, username]
      notNull: [make, model, passengers, dailyRate, fuelType ]
    - methodName: updateAuto
      isNull: [username]

    - methodName: createRenter
      isNull: [id, username]
      notNull: [make, firstName, lastName, dob, email]
    - methodName: updateRenter
      isNull: [username]

The JUnit test case uses real, secured AutosService and RenterServices @Autowired from the Spring context augmented with aspects. Your aspect will be included when the aop profile is active.

The JUnit tests will invoke the security service wrappers directly and through the controllers — calling with valid and invalid parameters according to the definition in the application-aop.yaml file.

Ungraded activity — create a breakpoint in the Advice and Autos/RentersService(s) when executing the tests. Observe the call stack to see how you got to that point, where you are headed, and what else is in that call stack.