FAQ

What is the difference between a forced authentication and a non-forced authentication and how are they used in Policy?

FAQ ID:    FAQ2226
Version:    2.0
Status:    Published
Published date:    07/17/2012
Updated:    07/18/2013
 

Answer


The difference between a forced and a non-forced authentication in Policy is fairly small, but can make a very large difference in how requests are processed for users.

Forced Authentication:

In a forced authentication rule, the ProxySG requests authentication of the user making the request. If, for any reason, the user does not authenticate against the realm specified in the authentication request, the request will be denied without the ProxySG needing to process the request against the rest of the Policy.

Authentication (non-forced):

In a non-forced authentication rule, the ProxySG requests authentication for the user making the request. If, for any reason, the user does not authenticate against the realm specified in the authentication request, the request will still be processed against all layers in the Policy, however the user will be listed as unauthenticated, meaning that for any rules where the Allow/Deny is dependent upon the user being authenticated, the rule will not match.

 

Examples of how this affects user access:

Forced auth:

A user requests access to a site that policy would allow for them. The ProxySG requests authentication credentials and they are not provided. The user is not authenticated, but since the authentication is forced, the user is denied access to the site. The rules further along in the Policy within the Web Access layers do not get processed because the failed authentication stops everything.

 

Non-forced auth:

The same request for the same user, in a non-forced authentication scenario would play out much differently, depending upon the rules in place in the Policy. If the Policy had a Default Allow rule, then the user would gain access to the requested content, so long as no rules blocked the content for all sources, including unauthenticated sources.

 

How is this useful?

 

Using a combination of forced and non-forced authentication rules makes it possible to build Policy that provides authentication, but also provides a 'Fail Open' feature for when authentication cannot occur due to network, AD, or other issues that can get in the way of a successful authentication. Careful crafting of the Policy on the ProxySG will allow for some requests to be allowed even when unauthenticated, while others, that need to be blocked, no matter what, still get blocked.

 


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question