authorize-requests.adoc 5.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126
  1. [[servlet-authorization-filtersecurityinterceptor]]
  2. = Authorize HttpServletRequest with FilterSecurityInterceptor
  3. :figures: servlet/authorization
  4. This section builds on xref:servlet/architecture.adoc#servlet-architecture[Servlet Architecture and Implementation] by digging deeper into how xref:servlet/authorization/index.adoc#servlet-authorization[authorization] works within Servlet based applications.
  5. The {security-api-url}org/springframework/security/web/access/intercept/FilterSecurityInterceptor.html[`FilterSecurityInterceptor`] provides xref:servlet/authorization/index.adoc#servlet-authorization[authorization] for ``HttpServletRequest``s.
  6. It is inserted into the xref:servlet/architecture.adoc#servlet-filterchainproxy[FilterChainProxy] as one of the xref:servlet/architecture.adoc#servlet-security-filters[Security Filters].
  7. .Authorize HttpServletRequest
  8. image::{figures}/filtersecurityinterceptor.png[]
  9. * image:{icondir}/number_1.png[] First, the `FilterSecurityInterceptor` obtains an xref:servlet/authentication/architecture.adoc#servlet-authentication-authentication[Authentication] from the xref:servlet/authentication/architecture.adoc#servlet-authentication-securitycontextholder[SecurityContextHolder].
  10. * image:{icondir}/number_2.png[] Second, `FilterSecurityInterceptor` creates a {security-api-url}org/springframework/security/web/FilterInvocation.html[`FilterInvocation`] from the `HttpServletRequest`, `HttpServletResponse`, and `FilterChain` that are passed into the `FilterSecurityInterceptor`.
  11. // FIXME: link to FilterInvocation
  12. * image:{icondir}/number_3.png[] Next, it passes the `FilterInvocation` to `SecurityMetadataSource` to get the ``ConfigAttribute``s.
  13. * image:{icondir}/number_4.png[] Finally, it passes the `Authentication`, `FilterInvocation`, and ``ConfigAttribute``s to the `AccessDecisionManager`.
  14. ** image:{icondir}/number_5.png[] If authorization is denied, an `AccessDeniedException` is thrown.
  15. In this case the xref:servlet/architecture.adoc#servlet-exceptiontranslationfilter[`ExceptionTranslationFilter`] handles the `AccessDeniedException`.
  16. ** image:{icondir}/number_6.png[] If access is granted, `FilterSecurityInterceptor` continues with the xref:servlet/architecture.adoc#servlet-filters-review[FilterChain] which allows the application to process normally.
  17. // configuration (xml/java)
  18. By default, Spring Security's authorization will require all requests to be authenticated.
  19. The explicit configuration looks like:
  20. .Every Request Must be Authenticated
  21. ====
  22. .Java
  23. [source,java,role="primary"]
  24. ----
  25. protected void configure(HttpSecurity http) throws Exception {
  26. http
  27. // ...
  28. .authorizeHttpRequests(authorize -> authorize
  29. .anyRequest().authenticated()
  30. );
  31. }
  32. ----
  33. .XML
  34. [source,xml,role="secondary"]
  35. ----
  36. <http>
  37. <!-- ... -->
  38. <intercept-url pattern="/**" access="authenticated"/>
  39. </http>
  40. ----
  41. .Kotlin
  42. [source,kotlin,role="secondary"]
  43. ----
  44. fun configure(http: HttpSecurity) {
  45. http {
  46. // ...
  47. authorizeRequests {
  48. authorize(anyRequest, authenticated)
  49. }
  50. }
  51. }
  52. ----
  53. ====
  54. We can configure Spring Security to have different rules by adding more rules in order of precedence.
  55. .Authorize Requests
  56. ====
  57. .Java
  58. [source,java,role="primary"]
  59. ----
  60. protected void configure(HttpSecurity http) throws Exception {
  61. http
  62. // ...
  63. .authorizeHttpRequests(authorize -> authorize // <1>
  64. .mvcMatchers("/resources/**", "/signup", "/about").permitAll() // <2>
  65. .mvcMatchers("/admin/**").hasRole("ADMIN") // <3>
  66. .mvcMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')") // <4>
  67. .anyRequest().denyAll() // <5>
  68. );
  69. }
  70. ----
  71. .XML
  72. [source,xml,role="secondary"]
  73. ----
  74. <http> <!--1-->
  75. <!-- ... -->
  76. <!--2-->
  77. <intercept-url pattern="/resources/**" access="permitAll"/>
  78. <intercept-url pattern="/signup" access="permitAll"/>
  79. <intercept-url pattern="/about" access="permitAll"/>
  80. <intercept-url pattern="/admin/**" access="hasRole('ADMIN')"/> <!--3-->
  81. <intercept-url pattern="/db/**" access="hasRole('ADMIN') and hasRole('DBA')"/> <!--4-->
  82. <intercept-url pattern="/**" access="denyAll"/> <!--5-->
  83. </http>
  84. ----
  85. .Kotlin
  86. [source,kotlin,role="secondary"]
  87. ----
  88. fun configure(http: HttpSecurity) {
  89. http {
  90. authorizeRequests { // <1>
  91. authorize("/resources/**", permitAll) // <2>
  92. authorize("/signup", permitAll)
  93. authorize("/about", permitAll)
  94. authorize("/admin/**", hasRole("ADMIN")) // <3>
  95. authorize("/db/**", "hasRole('ADMIN') and hasRole('DBA')") // <4>
  96. authorize(anyRequest, denyAll) // <5>
  97. }
  98. }
  99. }
  100. ----
  101. ====
  102. <1> There are multiple authorization rules specified.
  103. Each rule is considered in the order they were declared.
  104. <2> We specified multiple URL patterns that any user can access.
  105. Specifically, any user can access a request if the URL starts with "/resources/", equals "/signup", or equals "/about".
  106. <3> Any URL that starts with "/admin/" will be restricted to users who have the role "ROLE_ADMIN".
  107. You will notice that since we are invoking the `hasRole` method we do not need to specify the "ROLE_" prefix.
  108. <4> Any URL that starts with "/db/" requires the user to have both "ROLE_ADMIN" and "ROLE_DBA".
  109. You will notice that since we are using the `hasRole` expression we do not need to specify the "ROLE_" prefix.
  110. <5> Any URL that has not already been matched on is denied access.
  111. This is a good strategy if you do not want to accidentally forget to update your authorization rules.