1. What are authentication and authorization? Which must come first?

• Authentication – Establishing that a principal’s credentials are valid
• Authorization – Deciding if a principal is allowed to perform an action

Authentication comes first before Authorization because the authorization process needs a principal object with authority votes to decide the user is allowed to perform an action for the secured resource.

Authentication is the process of establishing that a principal is who they claim to be (a “principal” generally means a user, device or some other system which can perform an action in your application). Usually, a user authenticates to a system by using his username and password.

Authorization refers to the process of deciding whether a principal is allowed to perform an action within your application. To arrive at the point where an authorization decision is needed, the identity of the principal has already been established by the authentication process. For example, certain endpoints in your API can only be accessed by certain roles. When you call these endpoints with a role that does not have the privilege, the endpoint should throw an exception.

2. Is security a cross-cutting concern? How is it implemented internally?

Yes, security is a cross-cutting concern. Spring Security internally is implemented using AOP – the same way as Transactions management.

The cross-cutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and transactions.

• Yes, security is a cross-cutting concern.

Spring Security tackles security from two angles:

1. To secure web requests and restrict access at the URL level, Spring Security is based entirely on standard servlet filters.
   • It doesn’t use servlets or any other servlet-based frameworks (such as Spring MVC) internally, so it has no strong links to any particular web technology.
   • It deals in HttpServletRequest s and HttpServletResponse s and doesn’t care whether the requests come from a browser, a web service client, or AJAX.
   • Spring Security’s web infrastructure should only be used by delegating to an instance of FilterChainProxy .
2. Spring Security can also secure method invocations using Spring AOP, proxying objects and applying advice to ensure that the user has the proper authority to invoke secured methods.

Spring Security Configuration

Spring Security WebMvc under the hood

1. A user tries to access the application by making a request. The application requires the user to provide the credentials so it can be logged in.

2. The credentials are verified by the Authenticaltion Manager and the user is granted access to the application. The authorization rights for this user are loaded into the Spring Security context.

3. The user makes a resource request (view, edit, insert, or delete information) and the Security Interceptor intercepts the request before the user accesses a protected/secured resource.

4. The Security Interceptor extracts the user authorization data from the security context and…

5. …delegates the decision to the Access Decision Manager.

6. The Access Decision Manager polls a list of voters to return a decision regarding the rights of the authenticated user to system resources.

7. Access is granted or denied to the resource based on the user rights and the resource attributes.

Securing RESTful-WS three-step process:

1. a security filter named springSecurityFilterChain needs to be added, the filter is replaced by a class extending AbstractSecurityWebApplicationInitializer. This class registers DelegatingFilterProxy to use springSecurityFilterChain before any other registered Filter.

2. add a Spring configuration class for security where we will declare who can access the application and what they are allowed to do. In the case of this application, things are easy: we are using in-memory authentication for teaching purposes, so add a user named prospring5 with the password prospring5 and the role REMOTE.

@Configuration
 @EnableWebSecurity //enable secured behavior
 public class SecurityConfig extends WebSecurityConfigurerAdapter {

     private static Logger logger = LoggerFactory.getLogger(SecurityConfig.class);

     @Autowired
     protected void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
         auth.inMemoryAuthentication()
             .withUser("prospring5")
             .password("prospring5")
             .roles("REMOTE");
     }

     @Override
     protected void configure(HttpSecurity http) throws Exception {
         http.sessionManagement()
         .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
         .and()
         .authorizeRequests()
         .antMatchers("/**")
         .permitAll()
         .antMatchers("/rest/**")
         .hasRole("REMOTE")
         .anyRequest()
         .authenticated()
         .and()
         .formLogin()
         .and()
         .httpBasic()
         .and()
         .csrf()
         .disable();
     }

 }

           3. add the rest application context, besides adding SecurityConfig to the root context application.

public class WebInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

     @Override
     protected Class<?>[] getRootConfigClasses() {
         return new Class<?>[]{ DataServiceConfig.class, SecurityConfig.class};
     }

     @Override
     protected Class<?>[] getServletConfigClasses() {
         return new Class<?>[]{ WebConfig.class};
     }

     @Override
     protected String[] getServletMappings() {
         return new String[]{"/rest/**"};
     }
 }

Securing a Web Application //todo

Spring Security in Sprint Boot

If library spring-boot-starter-security is in the classpath, Spring Boot automatically secures all HTTP endpoints with basic authentication. This will add the

1. spring-security-core,
2. spring-security-config, and
3. springsecurity-web

dependencies to your project.

3. What is the delegating filter proxy?

DelegatingFilterProxy is the entry point for spring security. The DelegatingFilterProxy is a servlet filter and It should delegate the request to the spring managed bean that must implement the servlet Filter interface.

Delegating filter proxy is a servlet filter registered with the web container that delegates the requests to a Filter implementation on the Spring context side. That is there a 2 places servlet filters are attached to:

1. Web container 
2. Spring context

As of Spring Security, all requests pass through delegating filter proxy that is registered with the container and then goes to FilterChainProxy (another filter but this time on the Spring context side).

Delegating filter proxy may be declared in 2 ways:

1. In web.xml (from WEB-INF folder)
2. By extending AbstractSecurityWebApplicationInitializer

Delegating filter proxy will pass requests to the filter whose name is springSecurityFilterChain.

4. What is the security filter chain?

Spring Security provides a number of filters by default, and most of the time, these are enough.

Spring uses a chain of filters that is customizable by pulling in and taking out some filters as well as customizing them. This chain of filters is called the security filter chain (bean from the Spring context is called springSecurityFilterChain). Filters that build the chain are created when you enable web security.

Mandatory Filter Name Main Purpose?

1. SecurityContextIntegrationFilter – Establishes SecurityContext and maintains between HTTP requests
2. LogoutFilter – Clears SecurityContextHolder when logout requested
3. UsernamePasswordAuthenticationFilter – Puts Authentication into the SecurityContext on the login request
4. ExceptionTranslationFilter – Converts SpringSecurity exceptions into HTTP response or redirect
5. FilterSecurityInterceptor – Authorizes web requests based on config attributes and authorities

5. What is the security context?

The security context in Spring Security includes details of the principal currently using the application. The security context is always available to methods in the same thread of execution, even if the security context is not explicitly passed around as an argument to those methods. This information includes details about the principal. Context is held in the SecurityContextHolder.

There are several ways to determine who the user is. These are a few of the most common ways:

1. Inject a Principal object into the controller method.
2. Inject an Authentication object into the controller method.
3. Use SecurityContextHolder to get at the security context.
4. Use an @AuthenticationPrincipal annotated method.

• SecurityContext holds security information about the current thread of execution.
• This information includes details about the principal.
• Context is held in the SecurityContextHolder.
• By default the SecurityContextHolder uses a ThreadLocal to store these details, which means that the security context is always available to methods in the same thread of execution, even if the security context is not explicitly passed around as an argument to those methods.

Obtaining information about the current user:

Authentication authentication = SecurityContextHolder
    .getContext()
    .getAuthentication();

User user = (User) authentication.getPrincipal();

6. Why do you need the intercept-url?

<intercept-url/> from <http/> is used to define the URL for the requests that we want to have some security constraints. This tag has a pattern attribute that accepts either ant style paths or regex for matching the required resources. Access attribute accepts comma-separated roles that will be allowed to access the resource (any match will grant the access).

7. In which order do you have to write multiple intercept-url’s?

Most specific patterns must come first and most general last. When matching the specified patterns defined by element intercept-URL against an incoming request, the matching is done in the order in which the elements are declared. So the most specific patterns should come first and the most general should come last.

8. What does the ** pattern in an antMatcher or mvcMatcher do?

antMatcher(String antPattern) Allows configuring the HttpSecurity to only be invoked when matching the provided Ant-style pattern.

1. /admin/** matches any path starting with /admin.
2. The antMatcher(…) method is the equivalent of the <intercept-url.../> element from XML, and equivalent methods are available to replace the configuration for the login form, logout URL configuration, and CSRF token support.

mvcMatcher(String mvcPattern) Allows configuring the HttpSecurity to only be invoked when matching the provided Spring MVC pattern. Generally mvcMatcher is more secure than an antMatcher.

1. antMatchers("/secured") matches only the exact /secured URL
2. mvcMatchers("/secured") matches /secured as well as /secured/, /secured.html, /secured.xyz

9. Why is a mvcMatcher more secure than an antMatcher?

• MvcMatcher() uses Spring MVC’s HandlerMappingIntrospector to match the path and extract variables.
• They both implement RequestMatcher interface
• MvcMatcher can also restrict the URLs by HTTP method

In which order do you have to write multiple intercept-url’s?

• Patterns are always evaluated in the order they are defined.
• Most specific patterns must come first and most general last.

10. Does Spring Security support password hashing? What is salting?

Spring Security uses PasswordEncoder for encoding passwords. This interface has a Md5PasswordEncoder that allows for obtaining hashes of the password – that will be persisted. The problem is that there are “dictionaries” of hashes available on the internet and some hacker may just match the hash with a record from those dictionaries and gain unauthorized (from system’s point of view authorized) access. To avoid that you can add some “salt” to the pass before it is hashed. Perfectly that salt (which is some appended string) is some random value – a simpler implementation is to use the user id. 

There is an implementation of PasswordEncoder – BCryptPasswordEncoder that generates the salt automatically and thus you don’t have to bother about this.

11. Why do you need method security? What type of object is typically secured at the method level (think of its purpose, not its Java type).

If we secure only the web layer there may be a way to access the service layer in case we expose some REST endpoints. That’s why usually services are secured at the method level.

To apply security to lower layers of an application, Spring Security uses AOP. The respective bean is wrapped in a proxy that before calling the target method, first checks the credentials of the user and calls the method only if the user is authorized to call it.

Spring Security provides three different kinds of security annotations:

1. Spring Security’s own @Secured
2. JSR-250’s @RolesAllowed
3. Expression-driven annotations, with
   • @PreAuthorize and @PostAuthorize,
   • @PreFilter, and @PostFilter

The @Secured and @RolesAllowed annotations are the simplest options, restricting access based on what authorities have been granted to the user.

More flexibility in defining security rules on methods, Spring Security offers @PreAuthorize and @PostAuthorize. And @PreFilter/@PostFilter filter elements out of collections returned from or passed into a method.

@Secured

• Method-level security must be enabled by annotating a configuration class (good practice is to annotate the Security Configuration class to keep all configurations related to security in one place) with @EnableGlobalMethodSecurity(secured Enabled = true). Methods must be secured by annotating them with Spring Security annotation @Secured.
• When securedEnabled is true, a pointcut is created such that the Spring Security aspects will wrap bean methods that are annotated with @Secured.
• One drawback of the @Secured annotation is that it’s a Spring-specific annotation. If you’re more comfortable using annotations defined in Java standards, then perhaps you should consider using @RolesAllowed instead.

@Configuration
 @EnableWebSecurity
 @EnableGlobalMethodSecurity(securedEnabled = true)
 public class SecurityConfig extends WebSecurityConfigurerAdapter { }



@Service
 @Transactional(readOnly = true, propagation = Propagation.REQUIRED)
 public class UserServiceImpl implements UserService {

   @Secured("ROLE_ADMIN")
   public User findById(Long id) {
     return userRepo.findOne(id);
   }
 }

JSR-250 annotations

• Method-level security must be enabled by annotating a configuration class (good practice is to annotate the Security Configuration class to keep all configurations related to security in one place) with @EnableGlobalMethodSecurity(jsr250Enabled = true).
• jsr250Enabled and securedEnabled can be used together
• Methods must be secured by annotating them with JSR-250 annotations.
• With jsr250Enabled set to true, a pointcut will be effected such that any methods annotated with @RolesAllowed will be wrapped with Spring Security’s aspects.
• The JSR 250 annotations are standards-based and allow simple role-based constraints to be applied but do not have the power of Spring Security’s native annotations.
• The @RolesAllowed annotation is equivalent to @Secured in almost every way

@Configuration
 @EnableWebSecurity
 @EnableGlobalMethodSecurity(jsr250Enabled = true)
 public class SecurityConfig extends WebSecurityConfigurerAdapter { }





@Service
 @Transactional(readOnly = true, propagation = Propagation.REQUIRED)
 public class UserServiceImpl implements UserService {
   @RolesAllowed("ROLE_ADMIN")
   public User findById(Long id) {
     return userRepo.findOne(id);
   }
 }

Use SpEL to enable more security constraints on methods

• @PreAuthorize: Restricts access to a method before invocation based on the result of evaluating an expression
• @PostAuthorize: Allows a method to be invoked, but throws a security exception if the expression evaluates to false
• @PostFilter: Allows a method to be invoked, but filters the results of that method based on an expression
• @PreFilter: Allows a method to be invoked, but filters input prior to entering the method

@Secured, @PreAuthorize, or @RolesAllowed annotations at the class level as well!.

Each of these annotations accepts a SpEL expression for its value parameter. If the expression evaluates to true, then the security rule passes; otherwise, it fails. The implications of a passing versus failing security rule differ depending on which annotation is in use. You need to enable them by setting @EnableGlobalMethodSecurity’s prePostEnabled attribute to true:

@Configuration
 @EnableWebSecurity
 @EnableGlobalMethodSecurity(prePostEnabled = true)
 public class SecurityConfig extends WebSecurityConfigurerAdapter {}







@Service
 @Transactional(readOnly = true, propagation = Propagation.REQUIRED)
 public class UserServiceImpl implements UserService {
   @PreAuthorize("hasRole(’USER’)")
   public void create(User user){}
 }

12. What do @Secured and @RolesAllowed do? What is the difference between them?

@Secured and @RolesAllowed are the same the only difference is @RolesAllowed is a standard annotation (i.e. not only spring security) whereas @Secured is spring security only.

There are annotations used to declare some methods as secured. The difference between them is that @Secured is a Spring annotation while @RolesAllowed is a JSR250 annotation. For enabling @Secured annotation you have to set the securedEnabled attribute of @EnagleGlobalMethodSecurity to true:

13. What do @PreAuthorized and @RolesAllowed do? What is the difference between them?

@Secured and @RolesAllowed prevent a method from being executed unless the user has the required authority. But their weakness is that they’re only able to make their decisions based on the user’s granted authorities.

With SpEL expressions guiding access decisions, far more advanced security constraints can be written.

14. In which security annotation are you allowed to use SpEL?

1. @PreAuthorize
2. @PostAuthorize
3. @PreFilter
4. @PostFilter

For them to be accessible you have to enable the pre-post-attribute to “enabled” in the <global-method-security/> element.

• hasRole(role): Returns true if the current user has the specified role.
• hasAnyRole(role1,role2): Returns true if the current user has any of the supplied roles.
• isAnonymous(): Returns true if the current user is an anonymous user.
• isAuthenticated(): Returns true if the user is not anonymous.
• isFullyAuthenticated(): Returns true if the user is not an anonymous or Remember-Me user.

15. Is it enough to hide sections of my output (e.g. JSP-Page or Mustache template)?

• You can use a special tag for hiding or not generating parts of JSP depending on the access level.
• You can also verify the user has access to the URL and only allow accessing to the view based on the user.

16. Spring Security offers a security tag library for JSP, would you recognize it if you saw it in an example?

Spring Security Taglibs provides basic support for accessing security information.

Enable it:

1. Add spring‐security‐taglibs dependency.
2. Declare it in the JSP page <-- before use, need to import the taglib at the top of our JSP file: --> <%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %> Tags
3. Authorize Tag
   The authorize tag is used to determine whether the content written between the <sec:authorize> tags should be evaluated by the JSP. It can be used to display individual HTML elements—such as buttons—in the page, according to the granted authorities of the current user.
   • url attribute
   • ifAllGranted, ifNotGranted and ifAnyGranted were recently deprecated in favor of access attribute. “`jsp
   Editors only Login“`
4. authenticate tag is authentication The authenticate tag is used to access the contents of the current Authentication token in SecurityContext. It can be used to display information about the current user in the page. <sec:authentication property="principal.username"/> <sec:authorize access="isAuthenticated()"> Welcome Back, <sec:authentication property="name"/> </sec:authorize>