anchor.diff:  ----
   # curl -L -k -H "X-Remote-User: joe" \
     --cert /etc/pki/tls/certs/authproxy.pem \
  -  https://ose3-master.example.com:8443/oauth/token/request
  +  https://[MASTER]:8443/oauth/token/request
   ----
   
   If you do not supply the client certificate, the request should be denied:
   
   ----
   # curl -L -k -H "X-Remote-User: joe" \
  -  https://ose3-master.example.com:8443/oauth/token/request
  -----
  -
  -*Handling Logouts from the Web Console*
  -
  -The link:../architecture/infrastructure_components/web_console.html[web
  -console] manages its own sessions. When a user authenticates to Apache, in this
  -case there is another session at play. By default if the user clicks the logout
  -link from the web console, it only clears out the session cookie and delete the
  -token. However, Apache still thinks the user is logged in and immediately
  -triggers another log in.
  -
  -To handle this case, the web console's Asset Server has a setting that allows
  -admins to specify a logout URL:
  -
  -----
  -assetConfig:
  -  logoutURL: "https://ose3-master.example.com/logout"
  -----
  -
  -This page could be another `<Location>` in Apache that loads a static page for
  -clearing the form of authentication that is in use. This is especially useful
  -when using `mod_auth_form` in Apache 2.4. Basic Authentication logouts can be
  -challenging to support across all browsers, so it may simply be useful to
  -redirect to a page instructing the user to clear their authentication cache or
  -perhaps run `kdestroy` in the case of Kerberos.
  +  https://[MASTER]:8443/oauth/token/request
  +----
  +
   
   ====
   
  
positive.code: ----
    identityProviders:
    - name: requestheader
      challenge: false
      login: false
      provider:
        apiVersion: v1
        kind: RequestHeaderIdentityProvider
  
negative.code: 
  .Apache Authentication Using *RequestHeaderIdentityProvider*
  ====
  This example configures an authentication proxy on the same host as the Master.
  Having the proxy and Master on the same host is merely a convenience and may
  not be suitable for your environment. For example, if you were already running
  a link:../admin_guide/install/deploy_router.html[Router] on the Master port 443
  would not be available.
  
  It’s also important to note that while this reference configuration uses
  Apache's mod_auth_form it is by no means required and other proxies can easily
  be used if the following requirements are met:
  
  1. Block the X-Remote-User header from client requests to prevent spoofing.
  2. Enfore client certificate authentication in the
  RequestHeaderIdentityProvider configuration
  3. Require the X-Csrf-Token header be set for all authentication request using the challenge flow.
  4. Only the /oauth/authorize endpoint should be proxied and redirects should not be rewritten to allow the backend server to send the client to the correct location.
  
  *Install the prerequisites*
  
  `mod_auth_form` is shipped as part of the `mod_session` package that is found
  in the https://access.redhat.com/solutions/392003[Optional channel]:
  
  ----
  # yum install -y httpd mod_ssl mod_session apr-util-openssl
  ----
  
  Generate a CA for validating requests that submit the trusted header. This CA
  