How Allow, Deny and Require Statements Are Evaluated


Statements that control access to Webulator/400 sessions can appear within the session based configuration file.

If the server is evaluating access to a session for which no specific access control directives are specified and no parent session has access control specified, access will be granted. Otherwise, host filtering will be checked first. If access is allowed after host filtering (this includes the case where host filtering is not being used), user authentication will be checked.

Evaluating Host Filtering

When the server is evaluating whether to give access to a Webulator/400 session, it will work its way down the session tree from the root, evaluating host filtering rules from the highest session (closest to the root) to the lowest (closest to the session being evaluated).

For host filtering, the access directives are order, allow and deny. The order directive specifies the order in which the allow and deny directives are evaluated. The allow directive is used to add hosts which have access to a session. The deny directive removes hosts which have access to a session.

For the order values allow,deny and deny,allow, each set of directives may turn access on, turn it off or do nothing. Access will be turned on if the client's host matches an allow entry. It will be turned off if the host matches a deny entry. If neither the deny or allow entry matches the client's host, access will not be changed for that session. If both match the client's host, access will be set by the last entry evaluated (this depends on the order entry).

If order is set to mutual-failure, access will only be allowed if the client's host matches an allow entry and does not match a deny entry. Note that the effect of this is to ignore any previously evaluated directives from higher sessions.

Evaluating User Authentication

To evaluate user authentication, the server will find the directives in the session nearest to the session being evaluated (farthest from the root) that contains a require directive. If no such directive is found, access will be granted.

When evaluating the require entry(ies), the current authentication type, authentication user file and (possibly) authentication group file are used. If user authentication fails, the realm specified by the current authentication realm name is sent back to the browser to be displayed to the user when the browser prompts for a user name and password.


Also see Protecting your AS/400 information