Sometimes it is convenient to avoid your client browser, service or application getting a Kerberos challenge. Not all clients support getting such. Therefore Kantega SSO includes features both for avoiding Kerberos on configured IP subnets and User Agents.
This page sums up the two ways of configuring client restrictions.
In addition to restrict when kerberos should happen, Kantega SSO can also do the opposite. The Forced SSO feature allow users to be authenticated and recognized public pages (pages that normally do not trigger authentication) when valid kerberos tickets exist.
Client IP restrictions
The image below shows a screenshot from the IP restrictions configuration. You may enable Kerberos for any IP in the whitelist except what is given in the blacklist. Or you may disable Kerberos for IP given in the blacklist except what is given in the whitelist. Both blacklist and whitelist may contain regular expression syntax which is enabled by starting with ^ as the examples show.
NB: For Kantega Single Sign-on to perform IP restrictions, the correct IP must be communicated. Setting this up is explained in the yellow box in the image below.
User Agent restrictions
You may also restrict Kerberos from happening for a given User Agent. This is relevant if you have some client calling your Atlassian product that does not understand the Kerberos challenge Kantega Single Sign-on gives.
There is an already built-in list of known User Agents that is not Kerberos compatible. The functionality below lets you add your own User Agent restrictions to this list.
