Difference between revisions of "Access restrictions"
en>Santosh.thorat |
m (1 revision imported) |
Revision as of 00:31, 25 July 2021
Overview
Use Access Restriction to Allow/Deny access to SafeSquid's service for specific user/user groups. Allows you to specify the Access rights for various users and to profile the users into user groups for being uniquely processed in other sections.
In SafeSquid versions that support Windows Integrated Authentication, the Global Section allows you to explicitly Enable or Disable NTLM authentication. By setting this to "Disabled", you can explicitly switch off the support for Windows Integrated Authentication. If this option is enabled, SafeSquid offers authentication headers that encourage the client's browser to use Negotiate, NTLM or Basic Authentication, depending upon the browser's capabilities and user's system configuration.
Prerequisites
Access the SafeSquid User Interface
Go to Configure Page
Go to Application Setup |
|
Go to Access Restrictions |
|
GlobalDefault Access PolicyYou can set your Default Access Policy to either Allow or Deny. When you set your Default Access Policy as allow, all requests are allowed. Those that match an entry in the Deny Sub-Section are not allowed. Conversely, if you set the Default Access Policy set to deny, all requests are blocked. Those that match an entry in the Allow Sub-Section are not allowed. Recommended : If you set the default policy to Deny, you must create entries in the Allow sub-section. You do this to specify which users should be allowed access. Conversely, if you set the default policy to Allow, you must create entries in the Deny List Sub-Section. This is to specify which users should be denied access.
SSOEnable or Disable SSO Authentication.
|
|
Allow listWhen the Policy is Deny, requests matching an entry listed in this Allow SubSection are exclusively allowed access, denying all the other requests. The entries are matched in the top-down order, so the entry in the top of a sub-section is matched first. The first entry that matches is used for the connection, and the remaining entries are ignored. So the order of the entries listed are very important. Your Default Access Policies are as follows : |
|
Create new policy
EnabledEnable or Disable this entry
CommentFor documentation, and future references, explain the relevance of this entry with your policies. That is, by reading the policies, a future user can understand the purpose of that entry. |
|
Trace EntryEnable or Disable Tracing of this entry Select “Yes” to debug the application of entry using SafeSquid logs. Enable entry tracing, is useful if you wish to validate, its application.
LDAP ProfilesTo apply this rule, specify the LDAP users/groups/OUs. This can be done only when your LDAP Server is integrated with Safesquid. To integrate your LDAP Server with safesquid, use Integrate LDAP section. Example : Refer below link to configure LDAP section. Read more about Enable authentication for LDAP users ProfilesSpecify the Profiles applicable for this entry. This entry will be applicable only if the connection has any one of the specified profiles. Leave it Blank, to apply for all connections irrespective of any applied profile. To avoid application to a connection that has a profile, use negated profile (!profile). InterfaceWhen SafeSquid is listening on multiple interfaces, specify here the interface (IP: PORT) that you want this entry to apply to. Leaving it blank implies to all interfaces (leave it blank if SafeSquid is listening on only one interface). This can be used to: Allow access to the Web interface (http://safesquid.cfg), only on a specific interface (IP: PORT), to enhance security. Allow authenticated access on one interface, and unauthenticated access to specific websites on another. Make proxy.pac file at http://safesquid.cfg/template/proxy.pac available for auto proxy script and auto proxy detection on another interface, when only authenticated access is allowed on the primary interface. IP AddressSpecify the IP Address(es) you want this rule to match. If you wish the rule to match a specific IP address, simply specify that IP address. Alternatively, you can specify a comma separated list of IP addresses, if you want the rule to be matched for more than one IP address. You can also specify range of IPs. Example : 192.168.0.10-192.168.0.44 This will ensure all clients with IP addresses from 192.168.0.10 to 192.168.0.44 will be matched. If left blank, this rule will be applied to all the clients irrespective of their IP Address(es). When used in combination of User name field, matching users are allowed access only from IP's defined in this field. PAM authenticationEnables authentication for users. Users will be prompted for a username/password by their browser and required to enter a proper username/password.
Example : Refer below link for how to configure PAM Read more about Enable SSO authentication for LDAP users User nameThis field needs to be filled, only if you would want the user(s) to be authenticated, depending on the following conditions: a) With No Authentication selected, fill in the user name with which you would like the user to authenticate. b) With Pam Authentication selected, fill in existing user name(s) on the server configured for PAM, and leave the Password field blank. You can specify multiple user names, separated with pipe, e.g. ^(john|abraham|mary|laurent)$. Leaving this field blank allows authenticated access to all the users on the authenticating server. PasswordThis field needs to be filled in, you have filled in the User name field. This is the password for the user defined in the User name field. A user is allowed access, if he/she meets the authentication challenge, by responding with the entry in User name field, and this password. If you want authentication for roaming users or guest users we have default policy under Access Restriction Section on SafeSauid Interface. You have to just ENABLE the policy as TRUE as shown below.
|
|
AccessSpecify the features that connections matching this entry are allowed to access.
BypassSpecify the features which you can bypass for connections matching this entry. To match this entry, specify the features which you can bypass for connections.
Interface usernameYou can use this field, along with Interface password, to allow authenticated access to the Web Interface (http://safesquid.cfg). When you don’t define users, this single entry allows access to everyone, globally. A user is allowed access to the web interface of SafeSquid, only if he/she meets the authentication challenge, by responding with this User name field, and corresponding Password. Recommended : Create a second layer of security, for accessing the Web Interface by creating multiple proxy admin accounts, each possessing individual username and password for accessing the Web Interface. Interface passwordThis field needs to be filled in, only if you have filled in the Interface username field above. This is the password for the user defined in the Interface username field. A user is allowed access to the web interface of SafeSquid, if he/she meets the authentication challenge, by responding with this User name, and corresponding Password. If you want interface access through authentication we have default policy under Access Restriction Section on SafeSauid Interface.You have to just ENABLE the policy as TRUE as shown below. |
|
Add to User-GroupsGroup the users based on the similarities of their profiling going to be in the other sections. If you wish the users defined in this entry can be grouped with any existing groups, simply add those user groups here. If you wish to create a new user group for these users, give a new name to the new user group. When defining a new User Group, use terms that uniquely describes the user group. Deny listWhen the Default Access Policy is set to Allow, only requests matching an entry listed in this Deny SubSection are exclusively denied access, allowing all the other requests. The entries are matched in the top-down order, so the entry in the top of a sub-section is matched first, and the first entry that matches is used for the connection, and the remaining entries are ignored. So the order of the entries listed are very important. The all options in deny list will work same as Allow list |