migration.adoc 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123
  1. [[migration]]
  2. = Migrating to 6.0
  3. The Spring Security team has prepared the 5.8 release to simplify upgrading to Spring Security 6.0.
  4. Use 5.8 and
  5. ifdef::spring-security-version[]
  6. xref:5.8.0@migration.adoc[its preparation steps]
  7. endif::[]
  8. ifndef::spring-security-version[]
  9. its preparation steps
  10. endif::[]
  11. to simplify updating to 6.0
  12. After updating to 5.8, follow this guide to perform any needed migration steps.
  13. Also, this guide includes ways to <<revert,revert to 5.x>> behaviors and its defaults, should you run into trouble.
  14. == Servlet
  15. In Spring Security 5, the default behavior is for the xref:servlet/authentication/architecture.adoc#servlet-authentication-securitycontext[`SecurityContext`] to automatically be saved to the xref:servlet/authentication/persistence.adoc#securitycontextrepository[`SecurityContextRepository`] using the xref:servlet/authentication/persistence.adoc#securitycontextpersistencefilter[`SecurityContextPersistenceFilter`].
  16. Saving must be done just prior to the `HttpServletResponse` being committed and just before `SecurityContextPersistenceFilter`.
  17. Unfortunately, automatic persistence of the `SecurityContext` can surprise users when it is done prior to the request completing (i.e. just prior to committing the `HttpServletResponse`).
  18. It also is complex to keep track of the state to determine if a save is necessary causing unnecessary writes to the `SecurityContextRepository` (i.e. `HttpSession`) at times.
  19. In Spring Security 6, the default behavior is that the xref:servlet/authentication/persistence.adoc#securitycontextholderfilter[`SecurityContextHolderFilter`] will only read the `SecurityContext` from `SecurityContextRepository` and populate it in the `SecurityContextHolder`.
  20. Users now must explicitly save the `SecurityContext` with the `SecurityContextRepository` if they want the `SecurityContext` to persist between requests.
  21. This removes ambiguity and improves performance by only requiring writing to the `SecurityContextRepository` (i.e. `HttpSession`) when it is necessary.
  22. If you are explicitly opting into Spring Security 6's new defaults, the following configuration can be removed to accept the Spring Security 6 defaults.
  23. include::partial$servlet/architecture/security-context-explicit.adoc[]
  24. [[requestcache-query-optimization]]
  25. === Optimize Querying of `RequestCache`
  26. In Spring Security 5, the default behavior is to query the xref:servlet/architecture.adoc#savedrequests[saved request] on every request.
  27. This means that in a typical setup, that in order to use the xref:servlet/architecture.adoc#requestcache[`RequestCache`] the `HttpSession` is queried on every request.
  28. In Spring Security 6, the default is that `RequestCache` will only be queried for a cached request if the HTTP parameter `continue` is defined.
  29. This allows Spring Security to avoid unnecessarily reading the `HttpSession` with the `RequestCache`.
  30. In Spring Security 5 the default is to use `HttpSessionRequestCache` which will be queried for a cached request on every request.
  31. If you are not overriding the defaults (i.e. using `NullRequestCache`), then the following configuration can be used to explicitly opt into the Spring Security 6 behavior in Spring Security 5.8:
  32. include::partial$servlet/architecture/request-cache-continue.adoc[]
  33. === Use `AuthorizationManager` for Method Security
  34. There are no further migration steps for this feature.
  35. === Use `AuthorizationManager` for Message Security
  36. In 6.0, `<websocket-message-broker>` defaults `use-authorization-manager` to `true`.
  37. So, to complete migration, remove any `websocket-message-broker@use-authorization-manager=true` attribute.
  38. For example:
  39. ====
  40. .Xml
  41. [source,xml,role="primary"]
  42. ----
  43. <websocket-message-broker use-authorization-manager="true"/>
  44. ----
  45. ====
  46. changes to:
  47. ====
  48. .Xml
  49. [source,xml,role="primary"]
  50. ----
  51. <websocket-message-broker/>
  52. ----
  53. ====
  54. There are no further migrations steps for Java or Kotlin for this feature.
  55. == Reactive
  56. === Use `AuthorizationManager` for Method Security
  57. In 6.0, `@EnableReactiveMethodSecurity` defaults `useAuthorizationManager` to `true`.
  58. So, to complete migration, {security-api-url}org/springframework/security/config/annotation/method/configuration/EnableReactiveMethodSecurity.html[`@EnableReactiveMethodSecurity`] remove the `useAuthorizationManager` attribute:
  59. ====
  60. .Java
  61. [source,java,role="primary"]
  62. ----
  63. @EnableReactiveMethodSecurity(useAuthorizationManager = true)
  64. ----
  65. .Kotlin
  66. [source,kotlin,role="secondary"]
  67. ----
  68. @EnableReactiveMethodSecurity(useAuthorizationManager = true)
  69. ----
  70. ====
  71. changes to:
  72. ====
  73. .Java
  74. [source,java,role="primary"]
  75. ----
  76. @EnableReactiveMethodSecurity
  77. ----
  78. .Kotlin
  79. [source,kotlin,role="secondary"]
  80. ----
  81. @EnableReactiveMethodSecurity
  82. ----
  83. ====
  84. '''
  85. [[revert]]
  86. If you are running into trouble with any of the 6.0 changes, please first try to apply the following changes to get you up and running.
  87. It's more important to stay on 6.0 and get the security improvements.
  88. == Revert Servlet
  89. == Revert Reactive