updates to security section

Author: rsill-neo4j

modules/ROOT/pages/security/authentication.adoc

@@ -1,8 +1,6 @@
 = Authentication
 :description: This page describes how to set up authentication features in the Neo4j GraphQL Library.
 
-== `@authentication`
-
 The GraphQL Library offers the `@authentication` directive to configure authentication for certain operations and for different parts of your schema.
 
 [IMPORTANT]
@@ -11,14 +9,10 @@ Explicit authentication, configured with the `@authentication` directive, is onl
 Unauthenticated requests with queries requiring authentication never reach the database.
 ====
 
-=== Definition
+== Definition
 
 // tba
 
-=== Usage
-
-// tba - what could be moved to this section from below?
-
 == Operations
 
 Authentication can be configured to only be validated on certain operations:

modules/ROOT/pages/security/authorization.adoc

@@ -10,25 +10,13 @@ All authorization rules have an implied requirement for authentication, given th
 In the case of explicit authentication, configured using the xref::/security/authentication.adoc#_authentication[`@authentication`] directive, it is only evaluated during Cypher translation time.
 Unauthenticated requests with queries requiring authentication never reach the database.
 
-== `@authorization`
-
-=== Definition
-
-// tba
-
-=== Usage
-
-// tba - what could be moved to this section from below?
-
 [WARNING]
 ====
 The `@authorization` directive does not apply to subscriptions, it only applies to queries and mutations.
 Instead, use xref::/security/subscriptions-authorization.adoc[`@subscriptionsAuthorization`] to configure the authorization for subscriptions if you intend to use subscriptions in your API and want the events protected.
 ====
 
-== Rules
-
-=== Filtering
+== Filtering rules
 
 Filtering rules filter out data which users do not have access to, without throwing any errors. 
 These rules are translated into filtering predicates, which are evaluated against matched data in the database.
@@ -52,7 +40,7 @@ type Post @authorization(filter: [
 }
 ----
 
-==== Operations
+=== Operations
 
 Filtering can be configured to only be performed on certain operations:
 
@@ -82,7 +70,7 @@ In case there is no `operations` argument with a list of operations, the GraphQL
 ====
 
 
-=== Validating
+== Validating rules
 
 Validating rules throw an error if a query is executed against data which users do not have access to. 
 These rules are evaluated in the database via filtering predicates containing calls to 
@@ -104,7 +92,7 @@ type User @authorization(validate: [
 }
 ----
 
-==== Operations
+=== Operations
 
 Validation can be configured to only be performed on certain operations:
 

modules/ROOT/pages/security/subscriptions-authorization.adoc

@@ -4,21 +4,11 @@
 
 Subscriptions require their own authorization rules, which are configured with the `@subscriptionsAuthorization` directive.
 
-== `@subscriptionsAuthorization`
-
 Rules for subscriptions authorization are different to normal authorization rules.
 Only filtering rules are available for subscriptions events and there are more limitations in how they can be filtered.
 
 All subscriptions authorization rules have an implied requirement for authentication, given that the rules are normally evaluated against values in the JWT payload.
 
-=== Definition
-
-// tba
-
-=== Usage
-
-// tba - what could be moved to this section from below?
-
 == Filtering rules
 
 Filtering rules prevent events which contain information that users don't have access to from reaching them - they will receive no indication that this is the case.