icm/HTTP/auth_<xx> 
Use
With this parameter you can set up access restrictions in ICM and SAP Web Dispatcher.
To protect ICM and the back end system (AS ABAP or AS Java) there is an HTTP subhandler (filter), which can block requests using various criteria. When the filter is activated, it filters each HTTP(S) request to ICM or Web Dispatcher, before the request is sent to another HTTP handler (file access, cache, administration, redirect), or to the backend system (AS ABAP or AS Java).
More information:
SAP Web Dispatcher as
a URL Filter
You can filter requests according to the following criteria:
● URL
● Client IP address
● Server IP address
● User name/user group and password
● String search in the URL
Integration
The authentication subhandler extends the functions of the URL filter in SAP Web Dispatcher and the functions of the authentication of the Web-based administration interface.
When this access filter is used, the two other procedures can be deactivated:
● SAP Web Dispatcher URL filter:
wdisp/permission_table=
● Web administration interface:
icm/HTTP/admin_0 = PREFIX=/sap/admin,DOCROOT=./admin,AUTHFILE=none
Properties
Work area |
Internet Communication Manager, SAP Web Dispatcher |
Unit |
Character string |
Standard value |
icm/HTTP/auth_0= PREFIX=/, FILTER=SAP |
Dynamically modifiable |
no |
Value Range and Syntax
To set up access restrictions use the parameter with the following syntax:
icm/HTTP/auth_<xx> = PREFIX=<URL-Prefix>[,PERMFILE=<permission file>, AUTHFILE=<authentication file>, FILTER=<name>]
<xx> must be specified in ascending order from "0".
Not all combinations of options are possible. The following combinations are useful:
icm/HTTP/auth_<xx> = PREFIX =<prefix>
icm/HTTP/auth_<xx> = PREFIX =<prefix>, PERMFILE=<permfile>
icm/HTTP/auth_<xx> = PREFIX =<prefix>, PERMFILE=<permfile>, FILTER=<filtername>
icm/HTTP/auth_<xx> = PREFIX =<prefix>, PERMFILE=<permfile>, AUTHFILE=<authfile>
icm/HTTP/auth_<xx> = PREFIX =<prefix>, PERMFILE=<permfile>, AUTHFILE=<authfile>, FILTER=<filtername>
There is no point in having an AUTHFILE without a PERMFILE. It only makes sense to deactivate the filter if a PERMFILE is being used.
This is explained below.
● PREFIX
URL prefix for which the HTTP subhandler is to be called.
● PERMFILE
Optional specification:
Name of the permission file in the file system
● AUTHFILE
Optional specification:
Name of the user file or system for authenticating an operating system user
● FILTER
Optional specification:
Name of the
profile for the search template (standard value: SAP). If you leave out this option, you deactivate the
filter. The filter can be
dynamically activated/deactivated by setting the parameter csi/enable.
For more information, see Examining User Entries
in Program Commands. You can
dynamically activate/deactivate filtering using parameter csi/enable.
You can find this parameter in
transaction SMICM (see Using the ICM
Monitor) or the Web Administration
Interface.
PERMFILE
In the permission file you determine the type of access protection. The permission file has the following structure:
● Comment lines start with a # and are ignored.
● Other lines have the form:
P/D/S <URI pattern> <USER> <GROUP> <CLIENT IP> <SERVER IP>
where the letter at the start of the line has the following meaning:
○ P (Permit)lets the request through.
○ D (Deny)refuses the request and sends a message to the client.
○ S (Secure)only allows secure connections (HTTPS) for the URL prefix.
○ <URI pattern> is the section of the URL that is labeled in the cache key section as translated path.
● You can use the wildcard character * for the URI pattern, but only at the start or the end of the <URI pattern>string.
● You can use the wild card character * anywhere for the client and server IP address.
The default value of empty entries is *, which permits everything.
For a request to be allowed through with P (Permit), all the conditions must be fulfilled.
With D (Deny) only one condition has to be met for the request to be rejected.
The conditions are checked from top to bottom.
If one of the conditions for D or P is true, the check ends, and the request is permitted or denied by the subhandler.
Note that the URI permission table is case sensitive. So if you want to deny a URL or a user, only the exact capitalization as specified in the table is blocked.
Example
|
URI Pattern |
User |
Group |
Client IP Address |
Server IP Address |
D |
* |
* |
* |
10.18.55.01 |
|
D |
* |
* |
* |
* |
10.18.55.50 |
P |
/sap/admin |
* |
admin |
* |
10.18.55.40 |
P |
/sap/admin/* |
* |
admin |
10.*.55.* |
10.18.55.* |
D |
/* |
* |
* |
* |
* |
Use Positive Lists
Since the URL permission table is case sensitive, it is important to create the table as a positive list.
Execute all the URLs that are to be permitted, and at the end of the table set row D /* * * * *
Since IP addresses are not case sensitive, you can easily exclude single (or groups of) client or server IP addresses. Refer to the example.
AUTHFILE (optional)
The AUTHFILE determines the permitted users and passwords, and is required if entries for USER or GROUP are made in the permission file.
Possible values for AUTHFILE are:
● System
The user is authenticated against an operating system user.
● <File name>
File with user name, group name, and protected passwords.
The authorization file can be generated and maintained using programs wdispmon and icmon (option -a). It has the following structure:
● Comment lines start with a # and are ignored.
● Other lines have the form:
<user>:<password hash>:<user group>:<DN client certificate>
Example
Authentication for the ICM and SAP Web Dispatcher:
test:$apr1$/iTOQ$EOABCDFDDj55EqL0:user sidadm:$apr1$/iTOQ$EOcAYBCD55EqL0:admin |
More Information
Note the following documentation associated with this parameter:
Using Web Admin
Interface with X.509 Certificate
Using the Command Line
Programs icmon and wdispmon