SEC-624: Minor updates to docs

src/docbkx/namespace-config.xml

@@ -501,7 +501,9 @@
         attribute on the <literal>&lt;http&gt;</literal> element.
       </para>
       <para>
-        The CAS sample is a good example of the use of custom beans with the namespace, including this syntax.
+        The CAS sample is a good example of the use of custom beans with the namespace, including this syntax. If you aren't
+        familiar with authentication entry points, they are discussed in the <link xlink:href="#tech-auth-entry-point">technical
+          overview</link> chapter.
       </para>
     </section>  
     

src/docbkx/technical-overview.xml

@@ -317,6 +317,8 @@ if (obj instanceof UserDetails) {
     <literal>AuthenticationEntryPoint</literal>, an authentication
     mechanism, and an <literal>AuthenticationProvider</literal>.</para>
 
+    <section>
+      <title>ExceptionTranslationFilter</title>
       <para><literal>ExceptionTranslationFilter</literal> is an Acegi
         Security filter that has responsibility for detecting any Acegi
         Security exceptions that are thrown. Such exceptions will generally be
@@ -332,7 +334,10 @@ if (obj instanceof UserDetails) {
         launching an <literal>AuthenticationEntryPoint</literal> (if the
         principal has not been authenticated and therefore we need to go
         commence step three).</para>
+    </section>
 
+    <section xml:id="tech-auth-entry-point">
+      <title>AuthenticationEntryPoint</title>
     <para>The <literal>AuthenticationEntryPoint</literal> is responsible
     for step three in the above list. As you can imagine, each web
     application will have a default authentication strategy (well, this
@@ -353,7 +358,9 @@ if (obj instanceof UserDetails) {
     "<literal>Authentication</literal> request" object is built and then
     presented to an
     <interfacename>AuthenticationProvider</interfacename>.</para>
+    </section>
 
+    <section><title>AuthenticationProvider</title>
     <para>The last player in the Spring Security authentication process is
     an <literal>AuthenticationProvider</literal>. Quite simply, it is
     responsible for taking an <literal>Authentication</literal> request
@@ -374,7 +381,6 @@ if (obj instanceof UserDetails) {
     within the <literal>UserDetails</literal> object - will be used when
     building the fully populated <literal>Authentication</literal>
     object.</para>
-
     <para>After the authentication mechanism receives back the
       fully-populated <literal>Authentication</literal> object, it will deem
       the request valid, put the <literal>Authentication</literal> into the
@@ -384,6 +390,10 @@ if (obj instanceof UserDetails) {
       authentication mechanism will ask the user agent to retry (step two
       above).</para>
       
+    </section>
+    
+    <section>
+      <title>Setting the SecurityContextHolder Contents Directly</title>
       <para>Whilst this describes the typical authentication workflow, the
       good news is that Spring Security doesn't mind how you put an
       <literal>Authentication</literal> inside the
@@ -396,7 +406,7 @@ if (obj instanceof UserDetails) {
       <para>You can (and many users do) write their own filters or MVC
       controllers to provide interoperability with authentication systems
       that are not based on Spring Security. For example, you might be using
-    Container Managed Authentication which makes the current user
+      Container-Managed Authentication which makes the current user
       available from a ThreadLocal or JNDI location. Or you might work for a
       company that has a legacy proprietary authentication system, which is
       a corporate "standard" over which you have little control. In such
@@ -407,6 +417,7 @@ if (obj instanceof UserDetails) {
       object, and put it onto the SecurityContextHolder. It's quite easy to
       do this, and it is a fully-supported integration approach.</para>
     </section>
+  </section>
 
   <section xml:id="secure-objects">
     <info><title>Secure Objects</title></info>