Change the mapping of HTTP request methods

We can change the mapping of HTTP request methods to ACL permission bits by specifying values in the [http-method-perms] stanza of the web reverse proxy configuration file.

For example, to define that an HTTP method POST maps to the permission bits A and x, add the following entry to the [http-method-perms] stanza:

POST = Ax

We can also create custom permissions in custom action groups, for example, [my-action-group]t. See Custom permissions in custom action groups.

Here is an example [http-method-perms] stanza:

<default> = r
GET = r
HEAD = T
PUT = m
POST = Ax
DELETE = d
TRACE = [my-action-group]t

The <default> entry is always mandatory when adding any entries to the [http-method-perms] stanza.

The [http-method-perms] stanza can be specified on a per-junction basis by creating a stanza in the form of [http-method-perms:junction]. The values in the global [http-method-perms] stanza apply to any junctions that do not have a junction-specific stanza. A junction-specific stanza [http-method-perms:junction] does not inherit values from a global stanza. For information, see [http-method-perms] stanza.

The [http-method-perms] stanza is empty when the web reverse proxy instance is first configured. If the [http-method-perms] stanza is empty, the web reverse proxy defaults to the following ACL bits:

PUT => m 
DELETE => d
All else (GET,POST .. ) => r

Configuration validation

The configuration specified in the [http-method-perms] stanza is validated each time that a junction is created. The configuration is also validated when the web reverse proxy instance is restarted. This mechanism ensures the specified ACL bits correspond to actions already defined in the policy database.

The validation process of the [http-method-perms] configuration might cause authorization audit events to be generated. Such audit events will appear as unauthenticated accesses to the ISAM policy object /Permission-Configuration.

To suppress these audit events, attach a protected object policy (POP) with its audit-level attribute set to none to an object with the name /Permission-Configuration. This object is not created in the object space by default. The following pdadmin commands illustrate the creation of policy that will suppress the generation of these audit events:

pdadmin> objectspace create /Permission-Configuration 
"Permission configuration validation" 0 
pdadmin> pop create permission-configuration
pdadmin> pop modify permission-configuration set audit-level none
pdadmin> pop attach /Permission-Configuration permission-configuration

Parent topic: Default security policy