fixes

topics/authentication/kerberos.adoc

@@ -95,7 +95,7 @@ to _required_ then all users must have Kerberos enabled for their browser.
 ===== Configure Kerberos User Storage Federation Provider
 
 Now that the SPNEGO protocol is turned on at the authentication server, you'll need to configure how {{book.project.name}} interprets the Kerberos ticket.
-This is done through <fake/../../user-federation.adoc#_user-storage-federation,User Storage Federation>>. We have 2 different federation providers with Kerberos authentication support.
+This is done through <<fake/../../user-federation.adoc#_user-storage-federation,User Storage Federation>>. We have 2 different federation providers with Kerberos authentication support.
 
 If you want to authenticate with Kerberos backed by an LDAP server, you have to first configure the <<fake/../../user-federation/ldap.adoc#_ldap, LDAP Federation Provider>>.
 If you look at the configuration page for your LDAP provider you'll see a `Kerberos Integration` section.
@@ -168,7 +168,6 @@ GSSContext context = gssManager.createContext(serviceName, krb5Oid,
 ----        
 
 Note that you also need to configure `forwardable` kerberos tickets in `krb5.conf` file and add support for delegated credentials to your browser.
-For details, see the kerberos example from {{book.project.name}} examples set as mentioned above.
 
 WARNING: Credential delegation has some security implications so only use it if you really need it.
          It's highly recommended to use it together with HTTPS.

topics/clients.adoc

@@ -1,3 +1,4 @@
+[[_clients]]
 
 == Managing Clients
 

topics/overview/concepts.adoc

@@ -17,7 +17,7 @@ credentials::
 roles::
   Roles identify a type or category of user.  `Admin`, `user`, `manager`, and `employee` are all typical roles that may exist
   in an organization.  Applications often assign access and permissions to specific roles rather than individual users as dealing
-  with users can be too fine grained and hard to manage
+  with users can be too fine grained and hard to manage.
 user role mapping::
   A user role mapping defines a mapping between a role and a user.  A user can be associated with zero or more roles.  This
   role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on

topics/sso-protocols/oidc.adoc

@@ -55,9 +55,7 @@ to provide a client secret when they exchange the temporary codes for tokens.  _
 _Public_ clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the
 client.  HTML5/JavaScript clients actually always have to be _public_ clients because there is no way to transmit the client secret to them in a secure
 manner.  Again, this is ok so long as you use HTTPS and strictly enforce redirect URI registration.  This guide goes more detail
-into this in the
-
-// DOCS REMARK: Please update the cross-reference as it does not resolve correctly. <<fake/../../client.adoc,Client>> chapter.
+into this in the <<fake/../../clients.adoc#_clients, Managing Clients>> chapter.
 
 ===== Implicit Flow
 

topics/sso-protocols/saml.adoc

@@ -2,13 +2,11 @@
 
 === SAML
 
-link://https://saml.org/fill/this/in[SAML 2.0] is a similar specification to OIDC but a lot older and more mature.  It has its roots in SOAP and the plethora
+link:http://saml.xml.org/saml-specifications[SAML 2.0] is a similar specification to OIDC but a lot older and more mature.  It has its roots in SOAP and the plethora
 of WS-* specifications so it tends to be a bit more verbose than OIDC.  SAML 2.0 is primarily an authentication protocol
 that works by exchanging XML documents between the authentication server and the application.  XML signatures and encryption
 is used to verify requests and responses.
 
-In {{book.project.name}} SAML serves two types of use cases: browser applications and REST invocations.
-
 There is really two types of use cases when using SAML.  The first is an application that asks the {{book.project.name}} server to authenticate
 a user for them.  After a successful login, the application will receive an XML document that contains
 something called a SAML assertion that specify various attributes about the user.  This XML document is digitally signed by
@@ -55,7 +53,8 @@ You really don't need to know about this stuff, but it is a pretty clever trick.
 
 ===== ECP
 
-TODO.  Ask Pedro to fill in.
+ECP stands for "Enhanced Client or Proxy", a SAML v.2.0 profile which allows for the exchange of SAML attributes outside the context of a web browser.
+This is used most often for REST or SOAP-based clients.
 
 ====  {{book.project.name}} Server OIDC URI Endpoints