fixing remaining header issues so TOC levels are correct

SUMMARY.adoc

@@ -80,7 +80,7 @@
 
    .. link:topics/service/authorization/authorization-api.adoc[Authorization API]
 
-      ... link:topics/service/authorization/whatis-obtain-aat.adoc[What is a AAT and How to Obtain It]
+      ... link:topics/service/authorization/whatis-obtain-aat.adoc[What is an AAT and How to Obtain It]
 
       ... link:topics/service/authorization/authorization-api-aapi.adoc[Requesting Authorization Data and Token]
 

topics/enforcer/authorization-context.adoc

@@ -1,5 +1,5 @@
 [[_enforcer_authorization_context]]
-=== Obtaining the Authorization Context
+==== Obtaining the Authorization Context
 
 When policy enforcement is enabled, the permissions obtained from the server are available through `org.keycloak.AuthorizationContext`.
 This class provides several methods you can use to obtain permissions and ascertain whether a permission was granted for a particular resource or scope.

topics/enforcer/https.adoc

@@ -1,7 +1,7 @@
 [[_enforcer_filter_using_https]]
-=== Setting Up TLS/HTTPS
+==== Setting Up TLS/HTTPS
 
-When the server is using HTTPS, make sure your adapter is configured as follows:
+When the server is using HTTPS, ensure your adapter is configured as follows:
 
 .keycloak.json
 ```json
@@ -15,5 +15,5 @@ The configuration above enables TLS/HTTPS to the Authorization Client, making po
 {{book.project.name}} Server remotely using the HTTPS scheme.
 
 [NOTE]
-Is strongly recommended that you enable TLS/HTTPS when accessing the {{book.project.name}} Server endpoints.
+It is strongly recommended that you enable TLS/HTTPS when accessing the {{book.project.name}} Server endpoints.
 

topics/enforcer/js-adapter.adoc

@@ -1,5 +1,5 @@
 [[_enforcer_js_adapter]]
-=== JavaScript Integration
+==== JavaScript Integration
 
 The {{book.project.name}} Server comes with a JavaScript library you can use to interact with a resource server protected by a policy enforcer.
 This library is based on the {{book.external_link.keycloakjsadapter.link}}[{{book.project.name}} {{book.external_link.keycloakjsadapter.name}}], which can be integrated to allow your client to obtain permissions from a {{book.project.name}} Server.
@@ -26,7 +26,7 @@ The *keycloak-authz.js* library provides two main features:
 In both cases, the library allows you to easily interact with both resource server and {{book.project.name}} {{book.project.module}} to obtain tokens with
 permissions your client can use as bearer tokens to access the protected resources on a resource server.
 
-==== Handling Authorization Responses from a Resource Server
+===== Handling Authorization Responses from a Resource Server
 
 If a resource server is protected by a policy enforcer, it responds to client requests based on the permissions carried along with a <<fake/../keycloak-enforcement-bearer.adoc#_enforcer_bearer, bearer token>>.
 Typically, when you try to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
@@ -56,7 +56,7 @@ The `authorize` function is completely asynchronous and supports a few callback
 
 Most applications should use the `onGrant` callback to retry a request after a 401 response. Subsequent requests should include the RPT as a bearer token for retries.
 
-==== Obtaining Entitlements
+===== Obtaining Entitlements
 
 The keycloak-authz.js library provides an `entitlement` function that you can use to obtain an RPT from the server using the Entitlement API.
 
@@ -75,7 +75,7 @@ The `entitlement` function is completely asynchronous and supports a few callbac
 * `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
 * `onError`: The third argument of the function. Only called if the server responds unexpectedly.
 
-==== Obtaining the RPT
+===== Obtaining the RPT
 
 If you have already obtained an RPT using any of the authorization functions provided by the library, you can always obtain the RPT as follows from the authorization object (assuming that it has been initialized by one of the techniques shown earlier):
 

topics/enforcer/keycloak-enforcement-bearer.adoc

@@ -1,5 +1,5 @@
 [[_enforcer_bearer]]
-=== Protecting a Stateless Service Using a Bearer Token
+==== Protecting a Stateless Service Using a Bearer Token
 
 If the adapter is configured with the `bearer-only` configuration option, the policy enforcer decides whether a request
 to access a protected resource is allowed or denied based on the permissions of the bearer token.
@@ -21,7 +21,7 @@ In this example, a *keycloak.json* file in your application is similar to the fo
 ...
 ```
 
-==== Authorization Response
+===== Authorization Response
 
 When a client tries to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
 responds with a *401* status code and a `WWW-Authenticate` header. The value of the `WWW-Authenticate` header depends on the authorization protocol

topics/permission/typed-resource-permission.adoc

@@ -1,5 +1,5 @@
 [[_permission_typed_resource]]
-=== Typed Resource Permission
+==== Typed Resource Permission
 
 Resource permissions can also be used to define policies that are to be applied to all resources with a given <<fake/../../resource/create.adoc#_resource_create_type, type>>. This form of resource-based permission can be useful when you have resources sharing common access requirements and constraints.
 

topics/resource-server/default-config.adoc

@@ -41,6 +41,6 @@ image:../../images/resource-server/default-permission.png[alt="Default Permissio
 
 This permission is a <<fake/../../permission/create-resource.adoc#_permission_create_resource, resource-based permission>>, defining a set of one or more policies that are applied to all resources with a given type.
 
-=== Changing the Default Configuration
+==== Changing the Default Configuration
 
 You can change the default configuration by removing the default resource, policy, or permission definitions and creating your own.

topics/service/authorization/authorization-api-aapi.adoc

@@ -1,5 +1,5 @@
 [[_service_authorization_api_aapi]]
-=== Requesting Authorization Data and Token
+==== Requesting Authorization Data and Token
 
 Client applications using the UMA protocol can use a specific endpoint to obtain a special security token called a requesting party token (RPT).
 This token consists of all the permissions granted to a user as a result of the evaluation of the permissions and authorization policies associated with the resources being requested.
@@ -27,7 +27,7 @@ As a result, the server response is:
 {"rpt":"${RPT}"}
 ```
 
-==== Requesting Party Token 
+===== Requesting Party Token 
 
 A Requesting Party Token (RPT) is a https://tools.ietf.org/html/rfc7519[JSON web token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON Web Signature (JWS)].
 The token is built based on the AAT sent by the client during the authorization process.

topics/service/authorization/whatis-obtain-aat.adoc

@@ -1,5 +1,5 @@
 [[_service_authorization_aat]]
-=== What is a AAT and How to Obtain It
+==== What is an AAT and How to Obtain It
 
 An authorization API token (AAT) is a special OAuth2 access token with the scope *uma_authorization*. When you create a user, {{book.project.name}} automatically
 assigns the role _uma_authorization_ to the user. The _uma_authorization_ role is a default realm role.

topics/service/entitlement/entitlement-api-aapi.adoc

@@ -1,5 +1,5 @@
 [[_service_entitlement_api_aapi]]
-=== Requesting Entitlements
+==== Requesting Entitlements
 
 Client applications can use a specific endpoint to obtain a special security token called a requesting party token (RPT).
 This token consists of all the entitlements (or permissions) for a user as a result of the evaluation of the permissions and authorization policies associated with the resources being requested.
@@ -9,7 +9,7 @@ With an RPT, client applications can gain access to protected resources at the r
 http://${host}:${port}/auth/realms/${realm_name}/authz/entitlement
 ```
 
-==== Obtaining Entitlements
+===== Obtaining Entitlements
 
 The easiest way to obtain entitlements for a specific user is using an HTTP GET request. For example, using curl:
 
@@ -35,7 +35,7 @@ As a result, the server response is:
 Using this method to obtain entitlements, the server responds to the requesting client with *all* entitlements for a user, based on the evaluation of the permissions and
 authorization policies associated with the resources managed by the resource server.
 
-==== Obtaining Entitlements for a Specific Set of Resources
+===== Obtaining Entitlements for a Specific Set of Resources
 
 You can also use the entitlements endpoint to obtain a user's entitlements for a set of one or more resources. For example, using curl:
 
@@ -75,7 +75,7 @@ curl -X POST -H "Authorization: Bearer ${access_token}" -d '{
 }' "http://localhost:8080/auth/realms/hello-world-authz/authz/entitlement/hello-world-authz-service"
 ```
 
-==== Requesting Party Token
+===== Requesting Party Token
 
 A requesting party token (RPT) is a https://tools.ietf.org/html/rfc7519[JSON web token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON web signature (JWS)]. The token is built based on the access_token sent by the client during the authorization process.
 

topics/service/protection/permission-api-papi.adoc

@@ -1,5 +1,5 @@
 [[_service_protection_permission_api_papi]]
-=== Managing Permission Requests
+==== Managing Permission Requests
 
 Resource servers using the UMA protocol can use a specific endpoint to manage permission requests. This endpoint provides a UMA-compliant flow for registering permission requests and obtaining a permission ticket.
 

topics/service/protection/resources-api-papi.adoc

@@ -1,5 +1,5 @@
 [[_service_protection_resources_api]]
-=== Managing Resources
+==== Managing Resources
 
 Resource servers can manage their resources remotely using a UMA-compliant endpoint.
 

topics/service/protection/whatis-obtain-pat.adoc

@@ -1,5 +1,5 @@
 [[_service_protection_whatis_obtain_pat]]
-=== What is a PAT and How to Obtain It
+==== What is a PAT and How to Obtain It
 
 A *protection API token* (PAT) is a special OAuth2 access token with a scope defined as  *uma_protection*. When you create a resource server, {{book.project.name}} automatically
 creates a role, _uma_protection_, for the corresponding client application and associates it with the client's service account.