The Barracuda Web Application Firewall provides features to implement user authentication and access control. You can create a virtual private network (VPN) tunnel to control user access to websites. The user-access features allow you to specify who can access your websites and what access privileges each user has. By combining these with SSL encryption, you can create a secure VPN tunnel to your websites.
Authentication can be implemented only for HTTP or HTTPS services. The authentication process requires users to provide a valid name and password to gain access. A validated user has qualified access to the website; that is, the data and services this user can access depend on his authorization privileges. The following figure illustrates the authentication process:
The user accesses a login page (a GET request), a form for entering a username and password. The login form must be accessible to all users, but need not reside on a back-end server. The Barracuda Web Application Firewall includes a default login form which can be used instead of creating your own login page. The user submits the form (a POST request) and the Barracuda Web Application Firewall compares the submitted information against an internally or externally located authentication database. If successfully authenticated, the requester receives a cookie and is redirected to a success page. On subsequent requests, after verifying proper authorization (the authenticated user has the needed access privileges for the request) , the Barracuda Web Application Firewall forwards the request to the desired location.
If a user fails authentication, the user is redirected to a failed authorization page (not illustrated in the figure). When an authenticated user attempts to access an unauthorized page, for which he does not have permission, he is redirected to a denied authorization page.
Steps to Configure Access Control
To configure access control to your website, do the following:
- Configure an authentication database.
- Associate the authentication database with your website.
- Configure the authorization policy for your website.
Step 1 - Configuring an Authentication Database
An authentication database can be internal or external. To configure an internal database, set up local users and groups on the ACCESS CONTROL > Local User/Group page. To configure an external database, use the ACCESS CONTROL > Authentication Services page.
Configuring Internal Authentication Database
The Barracuda Web Application Firewall maintains an internal LDAP authentication database, to which the administrator is required to create users and groups using the ACCESS CONTROL > Local Users/Groups page. One or more users can be added to each group, and one user can belong to multiple groups.
To Create a Group
- Go to the ACCESS CONTROL > Local Users/Groups page. In the Groups section enter a name for the group in the New Group Name field.
- Click Add. The new group gets listed under Available Groups.
To Create a User
- Go to the ACCESS CONTROL > Local Users/Groups page. In the Users section, specify values for the following:
- New User Name – Enter a name for the user. Note that this is the username used to authenticate the user.
- Password – Enter a password for the user.
- User Groups – Select a group name from the list of groups and click Add. If you wish to associate the user to multiple groups, perform the same step again.
- Click Add.
Configuring External Authentication Database
External authentication databases are configured on the ACCESS CONTROL > Authentication Services page. The Barracuda Web Application Firewall supports the following authentication database servers:
Configuring LDAP Database Server
LDAP Authentication service identifies a database server supporting the LDAP protocol, which contains a set Authentication service. It is a unique identifier that identifies a set of users, groups, and contains mapping between the groups and the users. Configuration of this page allows the Barracuda Web Application Firewall to communicate with an existing LDAP directory server, and authenticate a user.
To enable LDAP user authentication:
- From the ACCESS CONTROL > Authentication Services page select the LDAP tab.
- Enter information about your LDAP server:
- Realm Name – Enter the name of the realm under which the Barracuda Web Application Firewall admins are stored (A realm identifies a collection of users and groups. It specifies information, in a flat directory structure, such as where users are located and where groups are located.).
- Server IP – Enter the IP address of the external LDAP server to authenticate users.
- Server Port – Enter the port number on which the server listens to LDAP connections. The standard LDAP ports are: port 389 for non-SSL connections and 636 for SSL connections.
- Secure Connection Type – Select the type of secure connection to be used by Barracuda Web Application Firewall when querying the LDAP database for user authentication and role retrieval.
- None – Establishes a plain text connection.
SSL/TLS – With SSL you can create a SSL socket and send/ receive LDAP messages over it. Typically LDAP server accepts SSL connections on port 636. The LDAP URI for this is defined as ldaps://
Transport Layer Security (TLS) protocol enables client/server applications to establish a secure connection over the Internet. TLS allows client/server applications to communicate in a way that is designed to prevent tampering or message forgery.
- StartTLS – Upgrades an existing insecure plain text connection by sending an extended request to encrypt the connection using TLS.
- Enter information about a user in your LDAP directory that has read access to all the users in LDAP directory:
- Bind DN – Enter Distinguished Name (DN) of the user to query the LDAP server.
- Base DN – Enter DN at which to start the search in the LDAP directory.
- Bind Password – Enter the password for the user querying the LDAP server.
- Login Attribute – Enter the attributes of an LDAP object used for identifying the user. For example: uid, sAMAccountName.
- Group Name Attribute – Enter the attributes of an LDAP object used for identifying the name of a group. Example: cn, sAMAccountName.
- Group Filter – Enter the filter attribute to retrieve the list of groups of the user in the LDAP directory. The maximum allowable characters are 500.
- Query For Group – Select Yes to query the groups in the LDAP directory for authentication. If set to No, queries are directed to individual user names for authentication.
- Optional. Test the entered values for connectivity, username binding, and encryption:
- Click Test LDAP. The Barracuda Web Application Firewall checks the information you provided.
- Check the test results displayed at the bottom of the page.
- If the test fails, you can either correct settings as needed and repeat Step 4, OR you can use the LDAP Discovery tool as described in the next step.
- Test the entered values and view troubleshooting details and recommendations (if any):
- Click LDAP Discovery. The Barracuda Web Application Firewall checks the information you provided.
- Check the test results:
- Verified information is indicated with a green dot next to the field.
- Information that need to be corrected is indicated with a red dot next to the field. Note: If you want to view detailed query results, click Verbose.
- If any information is incorrect or missing, edit fields as needed and then repeat Step 5.
- After your settings have been validated, click Add to save your settings.
Configuring RADIUS Database Server
The RADIUS protocol is based on a client/server model. The Barracuda Web Application Firewall can operate as a client of a RADIUS server. The client is responsible for passing user information to a designated RADIUS server and then acting on the response that is returned.
A RADIUS server (or daemon) can provide authentication and accounting services to one or more Barracuda Web Application Firewall devices. RADIUS servers are responsible for receiving user connection requests, authenticating users, and then returning all configuration information necessary for the client to deliver service to the users. A RADIUS server is generally a dedicated workstation connected to the network.
RADIUS Authentication service identifies a database server supporting the RADIUS protocol that contains a set of users, groups, and mapping between groups and users. This container allows the user to configure the Barracuda Web Application Firewall to communicate to an existing RADIUS directory server to authenticate a user.
To enable RADIUS user authentication:
- From the ACCESS CONTROL > Authentication Services page select the RADIUS tab.
- Enter information about your RADIUS server:
- Realm Name – Enter the name of a realm. A realm is a RADIUS compliant database of authorized user and group records. The realm can be located internally or externally on a RADIUS server.
- Server IP – Enter the IP address of the RADIUS server to authenticate users.
- Server Port – Enter the port number of the RADIUS server. Port 1812 is normally used for RADIUS.
- Shared Secret – Enter the secret key which is shared between the Barracuda Web Application Firewall and RADIUS server. Minimum value of the key is 6.
- Timeout – Enter the time in seconds for Barracuda Web Application Firewall to wait for a response from the RADIUS server before retransmitting the packet.
- Retries – Enter the number of times you want the Barracuda Web Application Firewall to transmit a request packet to the RADIUS server before giving up.
- Click Add to add your RADIUS server configuration.
Configuring a Secondary RADIUS Server
The Barracuda Web Application Firewall supports secondary RADIUS server for authenticating users. In case the primary RADIUS server fails, the secondary RADIUS server takes over as the primary RADIUS server for authenticating users. When configuring the secondary server, note all parameter values including shared secret of the secondary RADIUS server must be identical to the primary RADIUS server, except the server IP address and port number.
To configure a secondary RADIUS server
- Click Add next to the RADIUS authentication service for which you want to add the secondary server. The Authentication Services window appears, specify values for the following:
- Secondary Server IP – Specifies the IP address of the secondary RADIUS server.
- Secondary Server Port – Specifies the port number of the secondary RADIUS server.
- Click Add to add the secondary RADIUS server configuration
Configuring SITEMINDER Database Server
SiteMinder Authentication service identifies a database server supporting the SiteMinder protocol, which contains a set of users, groups, and mapping between groups and users. This container allows the user to configure the Barracuda Web Application Firewall to communicate to an existing SiteMinder directory server for authenticating a user.
To enable SITEMINDER user authentication
- From the ACCESS CONTROL > Authentication Services page select the SITEMINDER tab.
- Enter information about your SITEMINDER server:
- Realm Name – Enter the name of the realm under which the Barracuda Web Application Firewall admins are stored.
- Server IP – Enter the IP address of the SiteMinder Policy Server to authenticate users.
- Port – Enter the authentication port of the SiteMinder Policy Server. Port 44443 is the standard port used for SiteMinder.
- Enter information about a user in your SITEMINDER server that has privilege to access all the SITEMINDER policies in SITEMINDER server.
- Admin – Enter the privileged username for the SiteMinder Policy Server.
- Password – Enter the privileged user's password for the SiteMinder Policy Server.
Agent Name – Specifies the agent name configured in the SiteMinder Policy Server to represent Barracuda Web Application Firewall as SiteMinder agent.
- Host Conf Object – Enter the corresponding Host Configuration Object defined on the SiteMinder Policy Server.
- Shared WAF IP Addresses – Enter the IP address(es) of the Barracuda Web Application Firewall that share the user sessions. Each system specified here should set Single User Session to Yes on the ACCESS CONTROL > Authentication page to synchronize information between each other, and keep only one active session for a user. For example, consider you have two systems with the IP addresses 10.10.10.10 and 10.10.11.11. The system with IP address 10.10.10.10 should have 10.10.11.11 configured as Shared WAF IP Addresses and vise versa. Also, both systems should set Single User Session to Yes to synchronize information and keep only one active user session. Note: When configuring this parameter, all Barracuda Web Application Firewalls should have the same Realm Name and Cookie Encryption Key.
- Click Add to add your SITEMINDER server configuration.
Configuring RSA SECURID Database Server
RSA SecurID authentication service uses the RSA Authentication Manager database to authenticate the identity of users based on two factors: the current code generated on the user's assigned RSA SecurID authenticator, and a secret memorized Personal Identification Number (PIN) before granting access to protected resources.
To enable RSA SECURID user authentication:
- From the ACCESS CONTROL > Authentication Services page select the RSA SECURID tab.
- Enter information about your RSA RADIUS server:
- Realm Name – Enter the name of the realm under which the Barracuda Web Application Firewall admins are stored.
Server IP – Enter the IP address of the RSA RADIUS server to authenticate users.
- Server Port – Enter the port number of the RSA RADIUS server. Port 1812 is the standard port for RADIUS.
- Shared Secret – Enter the secret key which is shared between the Barracuda Web Application Firewall and the RSA RADIUS server. Minimum value of the key is 6.
- Timeout – Enter the time in seconds for Barracuda Web Application Firewall to wait for a response from the RSA RADIUS server before retransmitting the packet.
- Retries – Enter the number of times you want the Barracuda Web Application Firewall to transmit a request packet to the RSA RADIUS server before giving up.
- Click Add to add your RSA RADIUS server configuration.
Step 2 - Associating the authentication database with your website
The ACCESS CONTROL > Authentication page allows you to specify the parameters and resources to bind a configured authentication database with your Service and configure authentication of users.
Steps to associate an authentication database server with your website:
- From the ACCESS CONTROL > Authentication page identify the Service to which you want to bind an authentication database.
- Click Edit next to that Service. The Edit Authentication Policy window appears.
- In the Edit Authentication Policy section, set the Status to On and select the authentication database server from the Authentication Service drop-down list.
- Specify values to other parameters as required and click Save.
Step 3 - Configuring the authorization policy for your website
The ACCESS CONTROL > Authorization page allows you to configure custom access across your website allowing or denying users or groups access to specific services. Access control for a service is configured per URL and Host Match. Configure access control for a URL key of a service to restrict which users/groups can access that URL space. Customized access is configured by user and/or group.
Steps to configure an authorization policy for your website:
- Go to the ACCESS CONTROL > Authorization page. In the Add Authorization Policy section specify values for the following:
- Service – Select the Service to which you want to configure access control.
- Policy Name – Enter a name for the authorization policy.
- Status – Set to On to apply this authorization policy to the Service.
- URL Match – Enter a URL to be matched to the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. For example, /netbanking.html, any request matching this URL is required to authenticate before accessing this page. A value of “/*” means that the access control rule (ACL) applies for all URLs in that domain.
- Host Match – Enter a host name to be matched against the host in the request. This can be either a specific host match or a wildcard host match with a single “* “anywhere in the host name. For example, *.example.com, any request matching this host is required to authenticate before accessing this page.
- Extended Match – Define an expression that consists of a combination of HTTP headers and/or query string parameters. This expression is used to match against special attributes in the HTTP headers or query string parameters in the requests.
- Extended Match Sequence – Enter a number to indicate the order in which the extended match rule must be evaluated in the requests.
- Login Method –Select the login method to be used for authenticating users.
- Use Persistent Cookie - When set to Yes, the authentication cookies set in the browser by the Barracuda Web Application Firewall are valid for the time period specified in Persistent Cookie Timeout.
- Persistent Cookie Timeout - Enter the time in minutes to keep the persistent cookie valid, after which the cookie expires.
- Click Add to associate the authorization policy with the Service.
- To enforce fine grained access control, click Edit next to the Authorization Policy. The Edit Authorization Policy window appears.
- In the Edit Authorization Policy section, specify values for the following:
Allowed Users – Enter the list of users allowed to access the URL.
- Allowed Groups – Enter the list of allowed groups to access the URL.
Auth Not Done URL – Enter the URL where a user who attempts to access a protected URL before being authenticated will be redirected. If the URL is not specified, the user is redirected to the default login page generated by the Barracuda Web Application Firewall. Use this to redirect the user to a customized page or an error page instead of the default login page.
- Access Denied URL – Enter the URL where an authenticated user who lacks required access privileges should be redirected.
Send Basic Authentication – Select Yes to convert user credentials to HTTP Basic Authentication header, included in every request sent to the server. This is useful when Login Method is set to HTML Form, and when the server needs to know the user credentials. Two typical cases of the server needing to know the user credentials are:
- To implement single sign on. The server may require customization to process the Basic Authentication header, extract the user ID and password, and perform any authentication or authorization required by the Service so a user is not challenged to log in again.
- To personalize the home page, the server needs to know the user ID. Note: HTTP Basic Authentication Headers are sent in clear text, so it is not a secure means of exchanging user credentials. The user ID and password are visible in the data packets transmitted to the server. It is recommended that this option is used only when the traffic to the server is encrypted.
- Send Domain in Basic Authentication – If set to Yes, the domain information of the client is forwarded to the server along with the user credentials in the Basic Authentication Header. This is applicable only when Send Basic Authentication is set Yes.
- To perform advanced settings, specify values for the following in the Advanced section:
- Authorization Agent – The Barracuda Web Application Firewall is set as a default authorization agent to authorize users accessing this Service. This value remains the same for Services that are associated with the LDAP, RADIUS and RSA SECURID authentication services. For SITEMINDER authentication service, select SiteMinder as an authorization agent from the drop-down list to authorize users accessing SiteMinder protected resources.
Authorization Result Cache – Select an option from the drop-down list to cache the authorization result for allowed and denied responses.
- No Cache – Does not cache authorization results.
- Cache All – Caches all allowed and denied authorization results.
- Cache Allows – Caches only the allowed authorization results.
- Authorization Resource Depth – Enter the number of levels in the URI path of the request to be used for caching the authorization entries.
- Ignore Query String – Set to Yes if you wish to ignore query strings in the request while caching authorization entries.
- Click Save.