Reorganised the security page to explain that you need an authenticat…

…ion module in every case

People got a bit confused by that

docs/src/main/asciidoc/security-guide.adoc

@@ -7,7 +7,68 @@ https://github.com/quarkusio/quarkus/tree/master/docs/src/main/asciidoc
 
 include::./attributes.adoc[]
 
-## Securing REST endpoints
+Quarkus security allows you to define security authorization requirements for your code using annotations and/or configuration, and provides
+several ways to load security authentication information using Quarkus extensions.
+
+## Authentication sources
+
+Quarkus supports several sources to load authentication information from. You need to import at least one of the following extensions
+in order for Quarkus to know how to find the authentication information to check for authorizations:
+
+.Security Extensions
+|===
+|Extension |Description
+
+|link:elytron-properties-guide.html[quarkus-elytron-security-properties-file]
+|Provides support for simples properties files that can be used for testing security. This supports both embedding user info in `application.properties` and standalone properties files.
+
+|link:security-jdbc-guide.html[quarkus-elytron-security-jdbc]
+|Provides support for authenticating via JDBC.
+
+|link:oauth2-guide.html[quarkus-elytron-security-oauth2]
+|Provides support for OAuth2 flows using Elytron. This extension will likely be deprecated soon and replaced by a reactive Vert.x version.
+
+|link:jwt-guide.html[quarkus-smallrye-jwt]
+|A Microprofile JWT implementation that provides support for authenticating using Json Web Tokens. This also allows you to inject the token and claims into the application as per the MP JWT spec.
+
+|link:oidc-guide.html[quarkus-oidc]
+|Provides support for authenticating via an OpenID Connect provider such as Keycloak.
+
+|link:keycloak-authorization-guide.html[quarkus-keycloak-authorization]
+|Provides support for a policy enforcer using Keycloak Authorization Services.
+
+|===
+
+Please see the linked documents above for details on how to setup the various extensions.
+
+## Authenticating via HTTP
+
+Quarkus has two built in authentication mechanisms for HTTP based FORM and BASIC auth. This mechanism is pluggable
+however so extensions can add additional mechanisms (most notably OpenID Connect for Keycloak based auth).
+
+### Basic Authentication
+
+To enable basic authentication set `quarkus.http.auth.basic=true`. You must also have at least one extension installed
+that provides a username/password based `IdentityProvider`, such as link:security-jdbc-guide.html[Elytron JDBC].
+
+### Form Based Authentication
+
+Quarkus provides form based authentication that works in a similar manner to traditional Servlet form based auth. Unlike
+traditional form authentication the authenticated user is not stored in a HTTP session, as Quarkus does not provide
+clustered HTTP session support. Instead the authentication information is stored in an encrypted cookie, which can
+be read by all members of the cluster (provided they all share the same encryption key).
+
+The encryption key can be set using the `quarkus.http.auth.session.encryption-key` property, and it must be at least 16 characters
+long. This key is hashed using SHA-256 and the resulting digest is used as a key for AES-256 encryption of the cookie
+value. This cookie contains a expiry time as part of the encrypted value, so all nodes in the cluster must have their
+clocks synchronised. At one minute intervals a new cookie will be generated with an updated expiry time if the session
+is in use.
+
+The following properties can be used to configure form based auth:
+
+include::{generated-dir}/config/quarkus-http-auth-form.adoc[opts=optional, leveloffset=+1]
+
+## Authorization in REST endpoints and CDI beans using annotations
 
 Quarkus comes with build in security to allow for Role-Based Access Control (link:https://en.wikipedia.org/wiki/Role-based_access_control[RBAC])
 based on the common security annotations `@RolesAllowed`, `@DenyAll`, `@PermitAll` on REST endpoints and CDI beans.
@@ -66,79 +127,8 @@ public class SubjectExposingResource {
 <4> This call to obtain the user principal will return null if the caller is unauthenticated, non-null if the caller is authenticated.
 <5> The `/subject/denied` endpoint disallows any access regardless of whether the call is authenticated by specifying the `@DenyAll` annotation.
 
-## Configuration
-
-There are two configuration settings that alter the RBAC behavior:
-
-- `quarkus.jaxrs.deny-uncovered=true|false` - if set to true, the access will be denied for all JAX-RS endpoints will be
-denied by default. That is if the security annotations security annotations do not define the access control.
-Defaults to `false`
-- `quarkus.security.deny-unannotated=true|false` - if set to true, the access will be denied to all CDI methods
-and JAX-RS endpoints that do not have security annotations but are defined in classes that contain methods with
-security annotations. Defaults to `false`.
-
-## Security implementations
-
-Quarkus comes with several different Security extensions that provide different functionality. This functionality is
-very much a work in progress, so this list will be expanded over the coming weeks.
 
-
-.Security Extensions
-|===
-|Extension |Description
-
-|link:elytron-properties-guide.html[quarkus-elytron-security-properties-file]
-|Provides support for simples properties files that can be used for testing security. This supports both embedding user info in `application.properties` and standalone properties files.
-
-|link:security-jdbc-guide.html[quarkus-elytron-security-jdbc]
-|Provides support for authenticating via JDBC.
-
-|link:oauth2-guide.html[quarkus-elytron-security-oauth2]
-|Provides support for OAuth2 flows using Elytron. This extension will likely be deprecated soon and replaced by a reactive Vert.x version.
-
-|link:jwt-guide.html[quarkus-smallrye-jwt]
-|A Microprofile JWT implementation that provides support for authenticating using Json Web Tokens. This also allows you to inject the token and claims into the application as per the MP JWT spec.
-
-|link:oidc-guide.html[quarkus-oidc]
-|Provides support for authenticating via an OpenID Connect provider such as Keycloak.
-
-|link:keycloak-authorization-guide.html[quarkus-keycloak-authorization]
-|Provides support for a policy enforcer using Keycloak Authorization Services.
-
-
-|===
-
-Please see the linked documents above for details on how to setup the various extensions.
-
-### Authenticating Via HTTP
-
-Quarkus has two built in authentication mechanisms for HTTP based FORM and BASIC auth. This mechanism is pluggable
-however so extensions can add additional mechanisms (most notably OpenID Connect for Keycloak based auth).
-
-#### Basic Authentication
-
-To enable basic authentication set `quarkus.http.auth.basic=true`. You must also have at least one extension installed
-that provides a username/password based `IdentityProvider`, such as link:security-jdbc-guide.html[Elytron JDBC].
-
-#### Form Based Authentication
-
-Quarkus provides form based authentication that works in a similar manner to traditional Servlet form based auth. Unlike
-traditional form authentication the authenticated user is not stored in a HTTP session, as Quarkus does not provide
-clustered HTTP session support. Instead the authentication information is stored in an encrypted cookie, which can
-be read by all members of the cluster (provided they all share the same encryption key).
-
-The encryption key can be set using the `quarkus.http.auth.session.encryption-key` property, and it must be at least 16 characters
-long. This key is hashed using SHA-256 and the resulting digest is used as a key for AES-256 encryption of the cookie
-value. This cookie contains a expiry time as part of the encrypted value, so all nodes in the cluster must have their
-clocks synchronised. At one minute intervals a new cookie will be generated with an updated expiry time if the session
-is in use.
-
-The following properties can be used to configure form based auth:
-
-include::{generated-dir}/config/quarkus-http-auth-form.adoc[opts=optional, leveloffset=+1]
-
-
-### Securing Web Endpoints
+## Authorization of Web Endpoints using configuration
 
 Quarkus has an integrated plugable web security layer. If security is enabled all HTTP requests will have a permission
 check performed to make sure they are permitted to continue.
@@ -258,7 +248,19 @@ quarkus.http.auth.permission.roles2.policy=admin-policy1
 TIP: Given the above permission set, `GET /api/foo` would match both permission sets' paths,
 so would require both the `user` and `admin` roles.
 
+## Configuration
+
+There are two configuration settings that alter the RBAC behavior:
+
+- `quarkus.jaxrs.deny-uncovered=true|false` - if set to true, the access will be denied for all JAX-RS endpoints will be
+denied by default. That is if the security annotations security annotations do not define the access control.
+Defaults to `false`
+- `quarkus.security.deny-unannotated=true|false` - if set to true, the access will be denied to all CDI methods
+and JAX-RS endpoints that do not have security annotations but are defined in classes that contain methods with
+security annotations. Defaults to `false`.
+
 ### Registering Security Providers
+
 When running in native mode the default behavior for Graal native image generation is to only include the main "SUN" provider
 unless you have enabled SSL, in which case all security providers are registered. If you are not using SSL, then you can selectively
 register security providers by name using the `quarkus.security.users.security-providers` property. The following example illustrates