Where the authentication mode is set to pro-active each request on arrival will be passed to the defined authentication
mechanisms to eagerly perform authentication if there is sufficient information available in order to do so.
A pro-active authentication could be possible for a number of reasons such as already having a SSL connection
established, an identity being cached against the current session or even a browser sending in authentication headers.
Running in pro-active mode the sending of the challenge to the client is still driven by the constraints defined so this
is not the same as mandating security for all paths. For some mechanisms such as Digest this is a recommended mode as
without it there is a risk that clients are sending in headers with unique nonce counts that go unverified risking that a
malicious client could make use of them. This is also useful for applications that wish to make use of the current
authenticated user if one exists without mandating that authentication occurs.