Users : Offloading HTTP authentication & authorization : Applying user groups to an authorization realm
 
Applying user groups to an authorization realm
Authentication rules are used by the HTTP authentication policy to define sets of request URLs that will be authorized for each end-user group.
 
Alternatively, you can configure site publishing, which has the additional advantage of optionally providing SSO for multiple web applications. See “Single sign-on (SSO) (site publishing)”.
To configure an authentication rule
1. Before you can configure an authentication rule set, you must first configure any user groups that you want to include. For details, see “Grouping users”.
If you want to apply rules only to HTTP requests for a specific real or virtual host, you must first define the web host in a protected host names group. For details, see “Defining your protected/allowed HTTP “Host:” header names”.
2. Go to Application Delivery > Authentication Policy > Authentication Rule.
To access this part of the web UI, your administrator’s account access profile must have Read and Write permission to items in the Web Protection Configuration category. For details, see “Permissions”.
3. Click Create New.
A dialog appears.
4. In Name, type a name that can be referenced by other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.
5. If you want to require that the Host: field of the HTTP request matches a protected host entry in order to match the HTTP authentication rule, do the following:
Enable Host Status.
From Host, select which protected host entry (either a web host name or IP address) the Host: field of the HTTP request must be. The list contains hosts configured in a protected host names group. For details, see “Defining your protected/allowed HTTP “Host:” header names”.
6. Click OK.
7. Click Create New.
A dialog appears.
8. Configure these settings:
Setting name
Description
Auth Type
Select which type of HTTP authentication to use:
BasicClear text, Base64-encoded user name and password. Supports all user queries except NTLM. NTLM users will be ignored if included in the user group.
DigestHashed user name, realm, and password. Only local users are supported. Other types are ignored if included in the user group.
NTLMEncrypted user name and password. Only NTLM queries are supported. Other types are ignored if included in the user group.
For more information on available user types, see “Grouping users”.
User Group
Select the name of an existing end-user group that is authorized to use the URL in Auth Path.
User Realm
Type the realm, such as Restricted Area, to which the Auth Path belongs.
The realm is often used by browsers:
It may appear in the browser’s prompt for the user’s credentials. Especially if a user has multiple logins, and only one login is valid for that specific realm, displaying the realm helps to indicate which user name and password should be supplied.
After authenticating once, the browser may cache the authentication credentials for the duration of the browser session. If the user requests another URL from the same realm, the browser often will automatically re-supply the cached user name and password, rather than asking the user to enter them again for each request.
The realm may be the same for multiple authentication rules, if all of those URLs permit the same user group to authenticate.
For example, the user group All_Employees could have access to the Auth Path URLs /wiki/Main and /wiki/ToDo. These URLs both belong to the realm named Intranet Wiki. Because they use the same realm name, users authenticating to reach /wiki/Main usually will not have to authenticate again to reach /wiki/ToDo, as long as both requests are within the same browser session.
This field does not appear if Auth Type is NTLM, which does not support HTTP-style realms.
Auth Path
Type the literal URL, such as /employees/holidays.html, that a request must match in order to invoke HTTP authentication.
9. Click OK.
10. Repeat the previous steps for each user that you want to add to the authentication rules.
11. Group the authentication rule in an authentication policy. For details, see “Grouping authorization rules”.