Remove include servlet/saml2/index.adoc

docs/modules/ROOT/pages/servlet/authentication/anonymous.adoc

@@ -1,9 +1,9 @@
 [[anonymous]]
-== Anonymous Authentication
+= Anonymous Authentication
 
 
 [[anonymous-overview]]
-=== Overview
+== Overview
 It's generally considered good security practice to adopt a "deny-by-default" where you explicitly specify what is allowed and disallow everything else.
 Defining what is accessible to unauthenticated users is a similar situation, particularly for web applications.
 Many sites require that users must be authenticated for anything other than a few URLs (for example the home and login pages).
@@ -21,7 +21,7 @@ Classes can be authored more robustly if they know the `SecurityContextHolder` a
 
 
 [[anonymous-config]]
-=== Configuration
+== Configuration
 Anonymous authentication support is provided automatically when using the HTTP configuration Spring Security 3.0 and can be customized (or disabled) using the `<anonymous>` element.
 You don't need to configure the beans described here unless you are using traditional bean configuration.
 
@@ -88,7 +88,7 @@ For example:
 
 
 [[anonymous-auth-trust-resolver]]
-=== AuthenticationTrustResolver
+== AuthenticationTrustResolver
 Rounding out the anonymous authentication discussion is the `AuthenticationTrustResolver` interface, with its corresponding `AuthenticationTrustResolverImpl` implementation.
 This interface provides an `isAnonymous(Authentication)` method, which allows interested classes to take into account this special type of authentication status.
 The `ExceptionTranslationFilter` uses this interface in processing ``AccessDeniedException``s.
@@ -102,7 +102,7 @@ The `AuthenticatedVoter` approach is more powerful, since it allows you to diffe
 If you don't need this functionality though, then you can stick with `ROLE_ANONYMOUS`, which will be processed by Spring Security's standard `RoleVoter`.
 
 [[anonymous-auth-mvc-controller]]
-=== Getting Anonymous Authentications with Spring MVC
+== Getting Anonymous Authentications with Spring MVC
 
 https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-arguments[Spring MVC resolves parameters of type `Principal`] using its own argument resolver.
 

docs/modules/ROOT/pages/servlet/authentication/cas.adoc

@@ -1,8 +1,8 @@
 [[servlet-cas]]
-== CAS Authentication
+= CAS Authentication
 
 [[cas-overview]]
-=== Overview
+== Overview
 JA-SIG produces an enterprise-wide single sign on system known as CAS.
 Unlike other initiatives, JA-SIG's Central Authentication Service is open source, widely used, simple to understand, platform independent, and supports proxy capabilities.
 Spring Security fully supports CAS, and provides an easy migration path from single-application deployments of Spring Security through to multiple-application deployments secured by an enterprise-wide CAS server.
@@ -11,7 +11,7 @@ You can learn more about CAS at https://www.apereo.org.
 You will also need to visit this site to download the CAS Server files.
 
 [[cas-how-it-works]]
-=== How CAS Works
+== How CAS Works
 Whilst the CAS web site contains documents that detail the architecture of CAS, we present the general overview again here within the context of Spring Security.
 Spring Security 3.x supports CAS 3.
 At the time of writing, the CAS server was at version 3.4.
@@ -34,7 +34,7 @@ Authenticating a proxy ticket differs because the list of proxies must be valida
 
 
 [[cas-sequence]]
-==== Spring Security and CAS Interaction Sequence
+=== Spring Security and CAS Interaction Sequence
 The basic interaction between a web browser, CAS server and a Spring Security-secured service is as follows:
 
 * The web user is browsing the service's public pages.
@@ -87,7 +87,7 @@ It's good that you're still here!
 Let's now look at how this is configured
 
 [[cas-client]]
-=== Configuration of CAS Client
+== Configuration of CAS Client
 The web application side of CAS is made easy due to Spring Security.
 It is assumed you already know the basics of using Spring Security, so these are not covered again below.
 We'll assume a namespace based configuration is being used and add in the CAS beans as required.
@@ -96,7 +96,7 @@ A full CAS sample application can be found in the Spring Security <<samples,Samp
 
 
 [[cas-st]]
-==== Service Ticket Authentication
+=== Service Ticket Authentication
 This section describes how to setup Spring Security to authenticate Service Tickets.
 Often times this is all a web application requires.
 You will need to add a `ServiceProperties` bean to your application context.
@@ -194,7 +194,7 @@ In the following sections we will discuss some (optional) more advanced configur
 
 
 [[cas-singlelogout]]
-==== Single Logout
+=== Single Logout
 The CAS protocol supports Single Logout and can be easily added to your Spring Security configuration.
 Below are updates to the Spring Security configuration that handle Single Logout
 
@@ -271,14 +271,14 @@ The `SingleSignOutHttpSessionListener` ensures that when an `HttpSession` expire
 
 
 [[cas-pt-client]]
-==== Authenticating to a Stateless Service with CAS
+=== Authenticating to a Stateless Service with CAS
 This section describes how to authenticate to a service using CAS.
 In other words, this section discusses how to setup a client that uses a service that authenticates with CAS.
 The next section describes how to setup a stateless service to Authenticate using CAS.
 
 
 [[cas-pt-client-config]]
-===== Configuring CAS to Obtain Proxy Granting Tickets
+==== Configuring CAS to Obtain Proxy Granting Tickets
 In order to authenticate to a stateless service, the application needs to obtain a proxy granting ticket (PGT).
 This section describes how to configure Spring Security to obtain a PGT building upon thencas-st[Service Ticket Authentication] configuration.
 
@@ -335,7 +335,7 @@ An example configuration is shown below.
 ----
 
 [[cas-pt-client-sample]]
-===== Calling a Stateless Service Using a Proxy Ticket
+==== Calling a Stateless Service Using a Proxy Ticket
 Now that Spring Security obtains PGTs, you can use them to create proxy tickets which can be used to authenticate to a stateless service.
 The CAS <<samples,sample application>> contains a working example in the `ProxyTicketSampleServlet`.
 Example code can be found below:
@@ -379,7 +379,7 @@ protected fun doGet(request: HttpServletRequest, response: HttpServletResponse?)
 ====
 
 [[cas-pt]]
-==== Proxy Ticket Authentication
+=== Proxy Ticket Authentication
 The `CasAuthenticationProvider` distinguishes between stateful and stateless clients.
 A stateful client is considered any that submits to the `filterProcessUrl` of the `CasAuthenticationFilter`.
 A stateless client is any that presents an authentication request to `CasAuthenticationFilter` on a URL other than the `filterProcessUrl`.

docs/modules/ROOT/pages/servlet/authentication/events.adoc

@@ -1,5 +1,5 @@
 [[servlet-events]]
-== Authentication Events
+= Authentication Events
 
 For each authentication that succeeds or fails, a `AuthenticationSuccessEvent` or `AbstractAuthenticationFailureEvent` is fired, respectively.
 
@@ -68,7 +68,7 @@ class AuthenticationEvents {
 
 While similar to `AuthenticationSuccessHandler` and `AuthenticationFailureHandler`, these are nice in that they can be used independently from the servlet API.
 
-=== Adding Exception Mappings
+== Adding Exception Mappings
 
 `DefaultAuthenticationEventPublisher` by default will publish an `AbstractAuthenticationFailureEvent` for the following events:
 
@@ -121,7 +121,7 @@ fun authenticationEventPublisher
 ----
 ====
 
-=== Default Event
+== Default Event
 
 And, you can supply a catch-all event to fire in the case of any `AuthenticationException`:
 

docs/modules/ROOT/pages/servlet/authentication/jaas.adoc

@@ -1,21 +1,21 @@
 [[servlet-jaas]]
-== Java Authentication and Authorization Service (JAAS) Provider
+= Java Authentication and Authorization Service (JAAS) Provider
 
 
-=== Overview
+== Overview
 Spring Security provides a package able to delegate authentication requests to the Java Authentication and Authorization Service (JAAS).
 This package is discussed in detail below.
 
 
 [[jaas-abstractjaasauthenticationprovider]]
-=== AbstractJaasAuthenticationProvider
+== AbstractJaasAuthenticationProvider
 The `AbstractJaasAuthenticationProvider` is the basis for the provided JAAS `AuthenticationProvider` implementations.
 Subclasses must implement a method that creates the `LoginContext`.
 The `AbstractJaasAuthenticationProvider` has a number of dependencies that can be injected into it that are discussed below.
 
 
 [[jaas-callbackhandler]]
-==== JAAS CallbackHandler
+=== JAAS CallbackHandler
 Most JAAS ``LoginModule``s require a callback of some sort.
 These callbacks are usually used to obtain the username and password from the user.
 
@@ -33,7 +33,7 @@ If the `LoginModule` requests a callback against the ``InternalCallbackHandler``
 
 
 [[jaas-authoritygranter]]
-==== JAAS AuthorityGranter
+=== JAAS AuthorityGranter
 JAAS works with principals.
 Even "roles" are represented as principals in JAAS.
 Spring Security, on the other hand, works with `Authentication` objects.
@@ -50,14 +50,14 @@ However, there is a `TestAuthorityGranter` in the unit tests that demonstrates a
 
 
 [[jaas-defaultjaasauthenticationprovider]]
-=== DefaultJaasAuthenticationProvider
+== DefaultJaasAuthenticationProvider
 The `DefaultJaasAuthenticationProvider` allows a JAAS `Configuration` object to be injected into it as a dependency.
 It then creates a `LoginContext` using the injected JAAS `Configuration`.
 This means that `DefaultJaasAuthenticationProvider` is not bound any particular implementation of `Configuration` as `JaasAuthenticationProvider` is.
 
 
 [[jaas-inmemoryconfiguration]]
-==== InMemoryConfiguration
+=== InMemoryConfiguration
 In order to make it easy to inject a `Configuration` into `DefaultJaasAuthenticationProvider`, a default in-memory implementation named `InMemoryConfiguration` is provided.
 The implementation constructor accepts a `Map` where each key represents a login configuration name and the value represents an `Array` of ``AppConfigurationEntry``s.
 `InMemoryConfiguration` also supports a default `Array` of `AppConfigurationEntry` objects that will be used if no mapping is found within the provided `Map`.
@@ -65,7 +65,7 @@ For details, refer to the class level javadoc of `InMemoryConfiguration`.
 
 
 [[jaas-djap-config]]
-==== DefaultJaasAuthenticationProvider Example Configuration
+=== DefaultJaasAuthenticationProvider Example Configuration
 While the Spring configuration for `InMemoryConfiguration` can be more verbose than the standard JAAS configuration files, using it in conjunction with `DefaultJaasAuthenticationProvider` is more flexible than `JaasAuthenticationProvider` since it not dependant on the default `Configuration` implementation.
 
 An example configuration of `DefaultJaasAuthenticationProvider` using `InMemoryConfiguration` is provided below.
@@ -116,7 +116,7 @@ class="org.springframework.security.authentication.jaas.DefaultJaasAuthenticatio
 
 
 [[jaas-jaasauthenticationprovider]]
-=== JaasAuthenticationProvider
+== JaasAuthenticationProvider
 The `JaasAuthenticationProvider` assumes the default `Configuration` is an instance of https://docs.oracle.com/javase/8/docs/jre/api/security/jaas/spec/com/sun/security/auth/login/ConfigFile.html[ ConfigFile].
 This assumption is made in order to attempt to update the `Configuration`.
 The `JaasAuthenticationProvider` then uses the default `Configuration` to create the `LoginContext`.
@@ -157,7 +157,7 @@ class="org.springframework.security.authentication.jaas.JaasAuthenticationProvid
 ----
 
 [[jaas-apiprovision]]
-=== Running as a Subject
+== Running as a Subject
 If configured, the `JaasApiIntegrationFilter` will attempt to run as the `Subject` on the `JaasAuthenticationToken`.
 This means that the `Subject` can be accessed using:
 

docs/modules/ROOT/pages/servlet/authentication/logout.adoc

@@ -1,8 +1,8 @@
 [[jc-logout]]
-== Handling Logouts
+= Handling Logouts
 
 [[logout-java-configuration]]
-=== Logout Java/Kotlin Configuration
+== Logout Java/Kotlin Configuration
 
 When using the `{security-api-url}org/springframework/security/config/annotation/web/configuration/WebSecurityConfigurerAdapter.html[WebSecurityConfigurerAdapter]`, logout capabilities are automatically applied.
 The default is that accessing the URL `/logout` will log the user out by:
@@ -86,13 +86,13 @@ For many common scenarios, these handlers are applied under the
 covers when using the fluent API.
 
 [[ns-logout]]
-=== Logout XML Configuration
+== Logout XML Configuration
 The `logout` element adds support for logging out by navigating to a particular URL.
 The default logout URL is `/logout`, but you can set it to something else using the `logout-url` attribute.
 More information on other available attributes may be found in the namespace appendix.
 
 [[jc-logout-handler]]
-=== LogoutHandler
+== LogoutHandler
 
 Generally, `{security-api-url}org/springframework/security/web/authentication/logout/LogoutHandler.html[LogoutHandler]`
 implementations indicate classes that are able to participate in logout handling.
@@ -115,7 +115,7 @@ E.g. `deleteCookies()` allows specifying the names of one or more cookies to be
 This is a shortcut compared to adding a `CookieClearingLogoutHandler`.
 
 [[jc-logout-success-handler]]
-=== LogoutSuccessHandler
+== LogoutSuccessHandler
 
 The `LogoutSuccessHandler` is called after a successful logout by the `LogoutFilter`, to handle e.g.
 redirection or forwarding to the appropriate destination.
@@ -137,7 +137,7 @@ Instead of redirecting to a URL upon the successful logout, this `LogoutSuccessH
 If not configured a status code 200 will be returned by default.
 
 [[jc-logout-references]]
-=== Further Logout-Related References
+== Further Logout-Related References
 
 - <<ns-logout, Logout Handling>>
 - <<test-logout, Testing Logout>>

docs/modules/ROOT/pages/servlet/authentication/openid.adoc

@@ -1,5 +1,5 @@
 [[servlet-openid]]
-== OpenID Support
+= OpenID Support
 
 [NOTE]
 The OpenID 1.0 and 2.0 protocols have been deprecated and users are encouraged to migrate to OpenID Connect, which is supported by spring-security-oauth2.
@@ -27,7 +27,7 @@ Note that we have omitted the password attribute from the above user configurati
 A random password will be generated internally, preventing you from accidentally using this user data as an authentication source elsewhere in your configuration.
 
 
-=== Attribute Exchange
+== Attribute Exchange
 Support for OpenID https://openid.net/specs/openid-attribute-exchange-1_0.html[attribute exchange].
 As an example, the following configuration would attempt to retrieve the email and full name from the OpenID provider, for use by the application:
 

docs/modules/ROOT/pages/servlet/authentication/preauth.adoc

@@ -1,5 +1,5 @@
 [[servlet-preauth]]
-== Pre-Authentication Scenarios
+= Pre-Authentication Scenarios
 There are situations where you want to use Spring Security for authorization, but the user has already been reliably authenticated by some external system prior to accessing the application.
 We refer to these situations as "pre-authenticated" scenarios.
 Examples include X.509, Siteminder and authentication by the Java EE container in which the application is running.
@@ -16,7 +16,7 @@ If relying on container authentication, the user will be identified by calling t
 In some cases, the external mechanism may supply role/authority information for the user but in others the authorities must be obtained from a separate source, such as a `UserDetailsService`.
 
 
-=== Pre-Authentication Framework Classes
+== Pre-Authentication Framework Classes
 Because most pre-authentication mechanisms follow the same pattern, Spring Security has a set of classes which provide an internal framework for implementing pre-authenticated authentication providers.
 This removes duplication and allows new implementations to be added in a structured fashion, without having to write everything from scratch.
 You don't need to know about these classes if you want to use something like <<servlet-x509,X.509 authentication>>, as it already has a namespace configuration option which is simpler to use and get started with.
@@ -25,7 +25,7 @@ You will find classes under the `org.springframework.security.web.authentication
 We just provide an outline here so you should consult the Javadoc and source where appropriate.
 
 
-==== AbstractPreAuthenticatedProcessingFilter
+=== AbstractPreAuthenticatedProcessingFilter
 This class will check the current contents of the security context and, if empty, it will attempt to extract user information from the HTTP request and submit it to the `AuthenticationManager`.
 Subclasses override the following methods to obtain this information:
 
@@ -59,7 +59,7 @@ We'll look at a concrete example next.
 
 
 [[j2ee-preauth-details]]
-===== J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource
+==== J2eeBasedPreAuthenticatedWebAuthenticationDetailsSource
 If the filter is configured with an `authenticationDetailsSource` which is an instance of this class, the authority information is obtained by calling the `isUserInRole(String role)` method for each of a pre-determined set of "mappable roles".
 The class gets these from a configured `MappableAttributesRetriever`.
 Possible implementations include hard-coding a list in the application context and reading the role information from the `<security-role>` information in a `web.xml` file.
@@ -69,7 +69,7 @@ There is an additional stage where the roles (or attributes) are mapped to Sprin
 The default will just add the usual `ROLE_` prefix to the names, but it gives you full control over the behaviour.
 
 
-==== PreAuthenticatedAuthenticationProvider
+=== PreAuthenticatedAuthenticationProvider
 The pre-authenticated provider has little more to do than load the `UserDetails` object for the user.
 It does this by delegating to an `AuthenticationUserDetailsService`.
 The latter is similar to the standard `UserDetailsService` but takes an `Authentication` object rather than just user name:
@@ -85,19 +85,19 @@ This interface may have also other uses but with pre-authentication it allows ac
 The `PreAuthenticatedGrantedAuthoritiesUserDetailsService` class does this.
 Alternatively, it may delegate to a standard `UserDetailsService` via the `UserDetailsByNameServiceWrapper` implementation.
 
-==== Http403ForbiddenEntryPoint
+=== Http403ForbiddenEntryPoint
 The <<servlet-authentication-authenticationentrypoint,`AuthenticationEntryPoint`>> is responsible for kick-starting the authentication process for an unauthenticated user (when they try to access a protected resource), but in the pre-authenticated case this doesn't apply.
 You would only configure the `ExceptionTranslationFilter` with an instance of this class if you aren't using pre-authentication in combination with other authentication mechanisms.
 It will be called if the user is rejected by the `AbstractPreAuthenticatedProcessingFilter` resulting in a null authentication.
 It always returns a `403`-forbidden response code if called.
 
 
-=== Concrete Implementations
+== Concrete Implementations
 X.509 authentication is covered in its <<servlet-x509,own chapter>>.
 Here we'll look at some classes which provide support for other pre-authenticated scenarios.
 
 
-==== Request-Header Authentication (Siteminder)
+=== Request-Header Authentication (Siteminder)
 An external authentication system may supply information to the application by setting specific headers on the HTTP request.
 A well-known example of this is Siteminder, which passes the username in a header called `SM_USER`.
 This mechanism is supported by the class `RequestHeaderAuthenticationFilter` which simply extracts the username from the header.
@@ -110,7 +110,7 @@ Note that when using a system like this, the framework performs no authenticatio
 If an attacker is able to forge the headers in their original request without this being detected then they could potentially choose any username they wished.
 ====
 
-===== Siteminder Example Configuration
+==== Siteminder Example Configuration
 A typical configuration using this filter would look like this:
 
 [source,xml]
@@ -143,7 +143,7 @@ We've assumed here that the <<ns-config,security namespace>> is being used for c
 It's also assumed that you have added a `UserDetailsService` (called "userDetailsService") to your configuration to load the user's roles.
 
 
-==== Java EE Container Authentication
+=== Java EE Container Authentication
 The class `J2eePreAuthenticatedProcessingFilter` will extract the username from the `userPrincipal` property of the `HttpServletRequest`.
 Use of this filter would usually be combined with the use of Java EE roles as described above in <<j2ee-preauth-details>>.
 

docs/modules/ROOT/pages/servlet/authentication/rememberme.adoc

@@ -1,9 +1,9 @@
 [[servlet-rememberme]]
-== Remember-Me Authentication
+= Remember-Me Authentication
 
 
 [[remember-me-overview]]
-=== Overview
+== Overview
 Remember-me or persistent-login authentication refers to web sites being able to remember the identity of a principal between sessions.
 This is typically accomplished by sending a cookie to the browser, with the cookie being detected during future sessions and causing automated login to take place.
 Spring Security provides the necessary hooks for these operations to take place, and has two concrete remember-me implementations.
@@ -14,7 +14,7 @@ If you are using an authentication provider which doesn't use a `UserDetailsServ
 
 
 [[remember-me-hash-token]]
-=== Simple Hash-Based Token Approach
+== Simple Hash-Based Token Approach
 This approach uses hashing to achieve a useful remember-me strategy.
 In essence a cookie is sent to the browser upon successful interactive authentication, with the cookie being composed as follows:
 
@@ -50,7 +50,7 @@ The `UserDetailsService` will normally be selected automatically.
 If you have more than one in your application context, you need to specify which one should be used with the `user-service-ref` attribute, where the value is the name of your `UserDetailsService` bean.
 
 [[remember-me-persistent-token]]
-=== Persistent Token Approach
+== Persistent Token Approach
 This approach is based on the article https://web.archive.org/web/20180819014446/http://jaspan.com/improved_persistent_login_cookie_best_practice[http://jaspan.com/improved_persistent_login_cookie_best_practice] with some minor modifications  footnote:[Essentially, the username is not included in the cookie, to prevent exposing a valid login name unecessarily.
 There is a discussion on this in the comments section of this article.].
 To use the this approach with namespace configuration, you would supply a datasource reference:
@@ -74,7 +74,7 @@ create table persistent_logins (username varchar(64) not null,
 ----
 
 [[remember-me-impls]]
-=== Remember-Me Interfaces and Implementations
+== Remember-Me Interfaces and Implementations
 Remember-me is used with `UsernamePasswordAuthenticationFilter`, and is implemented via hooks in the `AbstractAuthenticationProcessingFilter` superclass.
 It is also used within `BasicAuthenticationFilter`.
 The hooks will invoke a concrete `RememberMeServices` at the appropriate times.
@@ -97,7 +97,7 @@ This design allows any number of remember-me implementation strategies.
 We've seen above that Spring Security provides two implementations.
 We'll look at these in turn.
 
-==== TokenBasedRememberMeServices
+=== TokenBasedRememberMeServices
 This implementation supports the simpler approach described in <<remember-me-hash-token>>.
 `TokenBasedRememberMeServices` generates a `RememberMeAuthenticationToken`, which is processed by `RememberMeAuthenticationProvider`.
 A `key` is shared between this authentication provider and the `TokenBasedRememberMeServices`.
@@ -130,7 +130,7 @@ The beans required in an application context to enable remember-me services are
 Don't forget to add your `RememberMeServices` implementation to your `UsernamePasswordAuthenticationFilter.setRememberMeServices()` property, include the `RememberMeAuthenticationProvider` in your `AuthenticationManager.setProviders()` list, and add `RememberMeAuthenticationFilter` into your `FilterChainProxy` (typically immediately after your `UsernamePasswordAuthenticationFilter`).
 
 
-==== PersistentTokenBasedRememberMeServices
+=== PersistentTokenBasedRememberMeServices
 This class can be used in the same way as `TokenBasedRememberMeServices`, but it additionally needs to be configured with a `PersistentTokenRepository` to store the tokens.
 There are two standard implementations.
 

docs/modules/ROOT/pages/servlet/authentication/runas.adoc

@@ -1,8 +1,8 @@
 [[runas]]
-== Run-As Authentication Replacement
+= Run-As Authentication Replacement
 
 [[runas-overview]]
-=== Overview
+== Overview
 The `AbstractSecurityInterceptor` is able to temporarily replace the `Authentication` object in the `SecurityContext` and `SecurityContextHolder` during the secure object callback phase.
 This only occurs if the original `Authentication` object was successfully processed by the `AuthenticationManager` and `AccessDecisionManager`.
 The `RunAsManager` will indicate the replacement `Authentication` object, if any, that should be used during the `SecurityInterceptorCallback`.
@@ -12,7 +12,7 @@ It will also be able to perform any internal security checks for specific `Grant
 Because Spring Security provides a number of helper classes that automatically configure remoting protocols based on the contents of the `SecurityContextHolder`, these run-as replacements are particularly useful when calling remote web services.
 
 [[runas-config]]
-=== Configuration
+== Configuration
 A `RunAsManager` interface is provided by Spring Security:
 
 [source,java]

docs/modules/ROOT/pages/servlet/authentication/session-management.adoc

@@ -1,9 +1,9 @@
 [[session-mgmt]]
-== Session Management
+= Session Management
 HTTP session related functionality is handled by a combination of the `SessionManagementFilter` and the `SessionAuthenticationStrategy` interface, which the filter delegates to.
 Typical usage includes session-fixation protection attack prevention, detection of session timeouts and restrictions on how many sessions an authenticated user may have open concurrently.
 
-=== Detecting Timeouts
+== Detecting Timeouts
 You can configure Spring Security to detect the submission of an invalid session ID and redirect the user to an appropriate URL.
 This is achieved through the `session-management` element:
 
@@ -74,7 +74,7 @@ Header always set Set-Cookie "JSESSIONID=;Path=/tutorial;Expires=Thu, 01 Jan 197
 
 
 [[ns-concurrent-sessions]]
-=== Concurrent Session Control
+== Concurrent Session Control
 If you wish to place constraints on a single user's ability to log in to your application, Spring Security supports this out of the box with the following simple additions.
 First, you need to add the following listener to your configuration to keep Spring Security updated about session lifecycle events:
 
@@ -165,7 +165,7 @@ If you are using a customized authentication filter for form-based login, then y
 More details can be found in the <<session-mgmt,Session Management chapter>>.
 
 [[ns-session-fixation]]
-=== Session Fixation Attack Protection
+== Session Fixation Attack Protection
 https://en.wikipedia.org/wiki/Session_fixation[Session fixation] attacks are a potential risk where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example).
 Spring Security protects against this automatically by creating a new session or otherwise changing the session ID when a user logs in.
 If you don't require this protection, or it conflicts with some other requirement, you can control the behavior using the `session-fixation-protection` attribute on `<session-management>`, which has four options
@@ -189,7 +189,7 @@ When session fixation protection occurs, it results in a `SessionFixationProtect
 If you use `changeSessionId`, this protection will __also__ result in any  ``javax.servlet.http.HttpSessionIdListener``s being notified, so use caution if your code listens for both events.
 See the <<session-mgmt,Session Management>> chapter for additional information.
 
-=== SessionManagementFilter
+== SessionManagementFilter
 The `SessionManagementFilter` checks the contents of the `SecurityContextRepository` against the current contents of the `SecurityContextHolder` to determine whether a user has been authenticated during the current request, typically by a non-interactive authentication mechanism, such as pre-authentication or remember-me  footnote:[
 Authentication by mechanisms which perform a redirect after authenticating (such as form-login) will not be detected by `SessionManagementFilter`, as the filter will not be invoked during the authenticating request.
 Session-management functionality has to be handled separately in these cases.
@@ -203,7 +203,7 @@ The most common behaviour is just to redirect to a fixed URL and this is encapsu
 The latter is also used when configuring an invalid session URL through the namespace, <<session-mgmt,as described earlier>>.
 
 
-=== SessionAuthenticationStrategy
+== SessionAuthenticationStrategy
 `SessionAuthenticationStrategy` is used by both `SessionManagementFilter` and `AbstractAuthenticationProcessingFilter`, so if you are using a customized form-login class, for example, you will need to inject it into both of these.
 In this case, a typical configuration, combining the namespace and custom beans might look like this:
 
@@ -230,7 +230,7 @@ Note that the use of the default, `SessionFixationProtectionStrategy` may cause
 See the Javadoc for this class for more information.
 
 [[concurrent-sessions]]
-=== Concurrency Control
+== Concurrency Control
 Spring Security is able to prevent a principal from concurrently authenticating to the same application more than a specified number of times.
 Many ISVs take advantage of this to enforce licensing, whilst network administrators like this feature because it helps prevent people from sharing login names.
 You can, for example, stop user "Batman" from logging onto the web application from two different sessions.
@@ -327,7 +327,7 @@ Without it, a user will never be able to log back in again once they have exceed
 
 
 [[list-authenticated-principals]]
-==== Querying the SessionRegistry for currently authenticated users and their sessions
+=== Querying the SessionRegistry for currently authenticated users and their sessions
 Setting up concurrency-control, either through the namespace or using plain beans has the useful side effect of providing you with a reference to the `SessionRegistry` which you can use directly within your application, so even if you don't want to restrict the number of sessions a user may have, it may be worth setting up the infrastructure anyway.
 You can set the `maximumSession` property to -1 to allow unlimited sessions.
 If you're using the namespace, you can set an alias for the internally-created `SessionRegistry` using the `session-registry-alias` attribute, providing a reference which you can inject into your own beans.

docs/modules/ROOT/pages/servlet/authentication/x509.adoc

@@ -1,9 +1,9 @@
 [[servlet-x509]]
-== X.509 Authentication
+= X.509 Authentication
 
 
 [[x509-overview]]
-=== Overview
+== Overview
 The most common use of X.509 certificate authentication is in verifying the identity of a server when using SSL, most commonly when using HTTPS from a browser.
 The browser will automatically check that the certificate presented by a server has been issued (ie digitally signed) by one of a list of trusted certificate authorities which it maintains.
 
@@ -19,7 +19,7 @@ For example, if you're using Tomcat then read the instructions here https://tomc
 It's important that you get this working before trying it out with Spring Security
 
 
-=== Adding X.509 Authentication to Your Web Application
+== Adding X.509 Authentication to Your Web Application
 Enabling X.509 client authentication is very straightforward.
 Just add the `<x509/>` element to your http security namespace configuration.
 
@@ -51,7 +51,7 @@ If no certificate is found, or no corresponding user could be found then the sec
 This means that you can easily use X.509 authentication with other options such as a form-based login.
 
 [[x509-ssl-config]]
-=== Setting up SSL in Tomcat
+== Setting up SSL in Tomcat
 There are some pre-generated certificates in the {gh-samples-url}/servlet/java-configuration/authentication/x509/server[Spring Security Samples repository].
 You can use these to enable SSL for testing if you don't want to generate your own.
 The file `server.jks` contains the server certificate, private key and the issuing certificate authority certificate.