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


<< Back to Knowledge Search

Solution

Overview


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.

 

Cause
Resolution
Workaround
Additional Information
Bug Number
InQuira Doc IdFAQ2226
Attachment

Article Feedback

Hide Properties
First Published      10/01/2014
Last Modified      10/01/2014
Last Published      10/01/2014
Article Audience
Product      ProxySG
Topic      Authentication
Article Number      000015360
Summary     
Was this helpful?
Comments:
 
Previous MonthNext Month
SunMonTueWedThuFriSat