BasicAccessList can be used to create complex authorization scenarios by combining other authorization types into a set of Required or Sufficient conditions. Each condition refers to an authorization type (for example, PermitUser, PairAuthorization, and so on) and Authentication task (Sufficient or Required). The conditions are evaluated sequentially. A connection is authorized if a Sufficient condition matches the connection, or all Required conditions are fulfilled. If a Required condition is not met, the connection is refused.

Figure 15.29. Using BasicAccessList

Figure 15.30. Creating BasicAccessList conditions

To create a new condition click New, and select the type of the condition from the Authentication task and Condition comboboxes. Then click on New, and enter the value for the condition (for example, the username or the name of the group).

When NEyesAuthorization is used, the client trying to access the service has to be authorized by another (already authorized) client (this authorization chain can be expanded to multiple levels). NEyesAuthorization can only be used in conjunction with another NEyesAuthorization policy. One of them is the authorizer set to authorize the authorized policy.

In a simple 4-eyes scenario the authorizer policy points to the authorized policy in its Authorization policy parameter, and has its Wait for other authorization policies to finish parameter disabled. The authorized policy has an empty Authorization policy parameter (meaning that it is at lower the end of an N-eyes chain), and has its Wait for other authorization policies to finish parameter enabled, meaning that it has to be authorized by another policy.

NEyesAuthorization has the following parameters:

When this authorization model is used, only two users simultaneously accessing the service are authorized, single users are not permitted to access the service. Set the time (in milliseconds) PNS will wait for the second user to access the service using the Max time for the pair to arrive spinbutton.

When setting this parameter, consider the timeout valuse set in the client application used to access the server. There is no use in specifying a longer time here, as the clients will time out anyway.

This model allows the members of the specified groups to access the service. Select the grouplist parameter and click Edit. In the appearing list editor window click New, then enter the name of an authorized usergroup. Additional groups can be added by clicking New again.

Figure 15.31. Using PermitGroup

This model allows the listed users to access the service. Select the userlist parameter and click Edit. In the appearing list editor window click New, then enter the name of an authorized user. Additional users can be added by clicking New again.

Figure 15.32. Using PermitUser

The PermitTime policy stores a set of intervals specified by their starting and ending time — access to a service using such a policy is permitted only within this interval.

To configure an interval, click on Edit, then click New. Select the first qstring value and click on Edit. Enter the starting time of the interval (for example, 8:30) and click Ok. The ending time of the interval can be set similarly through the second qstring value.