Remove include servlet/saml2/index.adoc

docs/modules/ROOT/pages/servlet/authorization/acls.adoc

@@ -1,8 +1,8 @@
 [[domain-acls]]
-== Domain Object Security (ACLs)
+= Domain Object Security (ACLs)
 
 [[domain-acls-overview]]
-=== Overview
+== Overview
 Complex applications often will find the need to define access permissions not simply at a web request or method invocation level.
 Instead, security decisions need to comprise both who (`Authentication`), where (`MethodInvocation`) and what (`SomeDomainObject`).
 In other words, authorization decisions also need to consider the actual domain object instance subject of a method invocation.
@@ -37,7 +37,7 @@ Fortunately, there is another alternative, which we'll talk about below.
 
 
 [[domain-acls-key-concepts]]
-=== Key Concepts
+== Key Concepts
 Spring Security's ACL services are shipped in the `spring-security-acl-xxx.jar`.
 You will need to add this JAR to your classpath to use Spring Security's domain object instance security capabilities.
 
@@ -130,7 +130,7 @@ We suggest taking a look over these for examples.
 
 
 [[domain-acls-getting-started]]
-=== Getting Started
+== Getting Started
 To get starting using Spring Security's ACL capability, you will need to store your ACL information somewhere.
 This necessitates the instantiation of a `DataSource` using Spring.
 The `DataSource` is then injected into a `JdbcMutableAclService` and `BasicLookupStrategy` instance.

docs/modules/ROOT/pages/servlet/authorization/expression-based.adoc

@@ -1,18 +1,18 @@
 
 [[el-access]]
-== Expression-Based Access Control
+= Expression-Based Access Control
 Spring Security 3.0 introduced the ability to use Spring EL expressions as an authorization mechanism in addition to the simple use of configuration attributes and access-decision voters which have been seen before.
 Expression-based access control is built on the same architecture but allows complicated Boolean logic to be encapsulated in a single expression.
 
 
-=== Overview
+== Overview
 Spring Security uses Spring EL for expression support and you should look at how that works if you are interested in understanding the topic in more depth.
 Expressions are evaluated with a "root object" as part of the evaluation context.
 Spring Security uses specific classes for web and method security as the root object, in order to provide built-in expressions and access to values such as the current principal.
 
 
 [[el-common-built-in]]
-==== Common Built-In Expressions
+=== Common Built-In Expressions
 The base class for expression root objects is `SecurityExpressionRoot`.
 This provides some common expressions which are available in both web and method security.
 
@@ -83,7 +83,7 @@ For example, `hasPermission(1, 'com.example.domain.Message', 'read')`
 
 
 [[el-access-web]]
-=== Web Security Expressions
+== Web Security Expressions
 To use expressions to secure individual URLs, you would first need to set the `use-expressions` attribute in the `<http>` element to `true`.
 Spring Security will then expect the `access` attributes of the `<intercept-url>` elements to contain Spring EL expressions.
 The expressions should evaluate to a Boolean, defining whether access should be allowed or not.
@@ -109,7 +109,7 @@ If expressions are being used, a `WebExpressionVoter` will be added to the `Acce
 So if you aren't using the namespace and want to use expressions, you will have to add one of these to your configuration.
 
 [[el-access-web-beans]]
-==== Referring to Beans in Web Security Expressions
+=== Referring to Beans in Web Security Expressions
 
 If you wish to extend the expressions that are available, you can easily refer to any Spring Bean you expose.
 For example, assuming you have a Bean with the name of `webSecurity` that contains the following method signature:
@@ -172,7 +172,7 @@ http {
 ====
 
 [[el-access-web-path-variables]]
-==== Path Variables in Web Security Expressions
+=== Path Variables in Web Security Expressions
 
 At times it is nice to be able to refer to path variables within a URL.
 For example, consider a RESTful application that looks up a user by id from the URL path in the format `+/user/{userId}+`.
@@ -240,13 +240,13 @@ http {
 In this configuration URLs that match would pass in the path variable (and convert it) into checkUserId method.
 For example, if the URL were `/user/123/resource`, then the id passed in would be `123`.
 
-=== Method Security Expressions
+== Method Security Expressions
 Method security is a bit more complicated than a simple allow or deny rule.
 Spring Security 3.0 introduced some new annotations in order to allow comprehensive support for the use of expressions.
 
 
 [[el-pre-post-annotations]]
-==== @Pre and @Post Annotations
+=== @Pre and @Post Annotations
 There are four annotations which support expression attributes to allow pre and post-invocation authorization checks and also to support filtering of submitted collection arguments or return values.
 They are `@PreAuthorize`, `@PreFilter`, `@PostAuthorize` and `@PostFilter`.
 Their use is enabled through the `global-method-security` namespace element:
@@ -256,7 +256,7 @@ Their use is enabled through the `global-method-security` namespace element:
 <global-method-security pre-post-annotations="enabled"/>
 ----
 
-===== Access Control using @PreAuthorize and @PostAuthorize
+==== Access Control using @PreAuthorize and @PostAuthorize
 The most obviously useful annotation is `@PreAuthorize` which decides whether a method can actually be invoked or not.
 For example (from the {gh-samples-url}/servlet/xml/java/contacts[Contacts] sample application)
 
@@ -412,7 +412,7 @@ This can be achieved using the `@PostAuthorize` annotation.
 To access the return value from a method, use the built-in name `returnObject` in the expression.
 --
 
-===== Filtering using @PreFilter and @PostFilter
+==== Filtering using @PreFilter and @PostFilter
 Spring Security supports filtering of collections, arrays, maps and streams using expressions.
 This is most commonly performed on the return value of a method.
 For example:
@@ -447,13 +447,13 @@ If you are filtering large collections and removing many of the entries then thi
 
 
 [[el-method-built-in]]
-==== Built-In Expressions
+=== Built-In Expressions
 There are some built-in expressions which are specific to method security, which we have already seen in use above.
 The `filterTarget` and `returnValue` values are simple enough, but the use of the `hasPermission()` expression warrants a closer look.
 
 
 [[el-permission-evaluator]]
-===== The PermissionEvaluator interface
+==== The PermissionEvaluator interface
 `hasPermission()` expressions are delegated to an instance of `PermissionEvaluator`.
 It is intended to bridge between the expression system and Spring Security's ACL system, allowing you to specify authorization constraints on domain objects, based on abstract permissions.
 It has no explicit dependencies on the ACL module, so you could swap that out for an alternative implementation if required.
@@ -494,7 +494,7 @@ Where `myPermissionEvaluator` is the bean which implements `PermissionEvaluator`
 Usually this will be the implementation from the ACL module which is called `AclPermissionEvaluator`.
 See the {gh-samples-url}/servlet/xml/java/contacts[Contacts] sample application configuration for more details.
 
-===== Method Security Meta Annotations
+==== Method Security Meta Annotations
 
 You can make use of meta annotations for method security to make your code more readable.
 This is especially convenient if you find that you are repeating the same complex expression throughout your code base.

docs/modules/ROOT/pages/servlet/authorization/method-security.adoc

@@ -1,12 +1,12 @@
 [[jc-method]]
-== Method Security
+= Method Security
 
 From version 2.0 onwards Spring Security has improved support substantially for adding security to your service layer methods.
 It provides support for JSR-250 annotation security as well as the framework's original `@Secured` annotation.
 From 3.0 you can also make use of new <<el-access,expression-based annotations>>.
 You can apply security to a single bean, using the `intercept-methods` element to decorate the bean declaration, or you can secure multiple beans across the entire service layer using the AspectJ style pointcuts.
 
-=== EnableMethodSecurity
+== EnableMethodSecurity
 
 In Spring Security 5.6, we can enable annotation-based security using the `@EnableMethodSecurity` annotation on any `@Configuration` instance.
 
@@ -149,7 +149,7 @@ class MethodSecurityConfig {
 ----
 ====
 
-==== Customizing Authorization
+=== Customizing Authorization
 
 Spring Security's `@PreAuthorize`, `@PostAuthorize`, `@PreFilter`, and `@PostFilter` ship with rich expression-based support.
 
@@ -245,7 +245,7 @@ We expose `GrantedAuthorityDefaults` using a `static` method to ensure that Spri
 ====
 
 [[jc-method-security-custom-authorization-manager]]
-==== Custom Authorization Managers
+=== Custom Authorization Managers
 
 Method authorization is a combination of before- and after-method authorization.
 
@@ -598,7 +598,7 @@ class MethodSecurityConfig {
 and it will be invoked after the `@PostAuthorize` interceptor.
 
 [[jc-enable-global-method-security]]
-=== EnableGlobalMethodSecurity
+== EnableGlobalMethodSecurity
 
 We can enable annotation-based security using the `@EnableGlobalMethodSecurity` annotation on any `@Configuration` instance.
 For example, the following would enable Spring Security's `@Secured` annotation.
@@ -740,7 +740,7 @@ interface BankService {
 ----
 ====
 
-=== GlobalMethodSecurityConfiguration
+== GlobalMethodSecurityConfiguration
 
 Sometimes you may need to perform operations that are more complicated than are possible with the `@EnableGlobalMethodSecurity` annotation allow.
 For these instances, you can extend the `GlobalMethodSecurityConfiguration` ensuring that the `@EnableGlobalMethodSecurity` annotation is present on your subclass.
@@ -776,7 +776,7 @@ open class MethodSecurityConfig : GlobalMethodSecurityConfiguration() {
 For additional information about methods that can be overridden, refer to the `GlobalMethodSecurityConfiguration` Javadoc.
 
 [[ns-global-method]]
-=== The <global-method-security> Element
+== The <global-method-security> Element
 This element is used to enable annotation-based security in your application (by setting the appropriate attributes on the element), and also to group together security pointcut declarations which will be applied across your entire application context.
 You should only declare one `<global-method-security>` element.
 The following declaration would enable support for Spring Security's `@Secured`:
@@ -889,7 +889,7 @@ If two annotations are found which apply to a particular method, then only one o
 ====
 
 [[ns-protect-pointcut]]
-=== Adding Security Pointcuts using protect-pointcut
+== Adding Security Pointcuts using protect-pointcut
 
 The use of `protect-pointcut` is particularly powerful, as it allows you to apply security to many beans with only a simple declaration.
 Consider the following example:

docs/modules/ROOT/pages/servlet/authorization/secure-objects.adoc

@@ -1,9 +1,9 @@
 
 [[secure-object-impls]]
-== Secure Object Implementations
+= Secure Object Implementations
 
 [[aop-alliance]]
-=== AOP Alliance (MethodInvocation) Security Interceptor
+== AOP Alliance (MethodInvocation) Security Interceptor
 Prior to Spring Security 2.0, securing ``MethodInvocation``s needed quite a lot of boiler plate configuration.
 Now the recommended approach for method security is to use <<ns-method-security,namespace configuration>>.
 This way the method security infrastructure beans are configured automatically for you so you don't really need to know about the implementation classes.
@@ -15,7 +15,7 @@ The interceptor uses a `MethodSecurityMetadataSource` instance to obtain the con
 `MapBasedMethodSecurityMetadataSource` is used to store configuration attributes keyed by method names (which can be wildcarded) and will be used internally when the attributes are defined in the application context using the `<intercept-methods>` or `<protect-point>` elements.
 Other implementations will be used to handle annotation-based configuration.
 
-==== Explicit MethodSecurityInterceptor Configuration
+=== Explicit MethodSecurityInterceptor Configuration
 You can of course configure a `MethodSecurityInterceptor` directly in your application context for use with one of Spring AOP's proxying mechanisms:
 
 [source,xml]
@@ -36,7 +36,7 @@ You can of course configure a `MethodSecurityInterceptor` directly in your appli
 ----
 
 [[aspectj]]
-=== AspectJ (JoinPoint) Security Interceptor
+== AspectJ (JoinPoint) Security Interceptor
 The AspectJ security interceptor is very similar to the AOP Alliance security interceptor discussed in the previous section.
 Indeed we will only discuss the differences in this section.