ZAS is a tool that allows Zorp services to be authenticated against existing user databases (backends). ZAS does not itself provide authentication services, it only mediates between Zorp and the backends. The traditional access control model in Zorp is based on verifying that a connection requesting a service from a source zone is allowed to access the service, and that the service is allowed to enter the destination zone. That is:

Using ZAS to authenticate the connections adds further requirements to this model: the client must successfully authenticate himself, and (optionally) must be allowed to access the service (that is, authorization can be also required). The actual procedure is as follows:

When the client initiates a connection, it actually tries to use a Zorp service. Zorp checks if an authentication policy is associated to the service. If an authentication policy is present, Zorp contacts a ZAS server (the authentication provider specified in the authentication policy). The ZAS server can connect to a user database (a backend) storing user information (passwords, certificates, and so on) required for a particular authentication method. (The type of the database determines which authentication methods can be used.) Each instance of a ZAS server can connect to a single backend, but multiple instances can be run from ZAS. When an authentication request arrives from Zorp, ZAS evaluates a number of configured routers: rules that determine which instance should be used to authenticate the connection. This decision is based on meta-information of the connection received from Zorp (for example, Client-IP, Username, and so on). The selected instance connects the client and the authentication is performed. The authentication can take place within the protocol (inband), or using a dedicated authentication agent (outband).

Figure 15.2. The operation of ZAS

If the authentication is successful, Zorp verifies that the client is allowed to access the service (by evaluating the authorization policy). If the client is authorized to access the service, the server-side connection is built. The client is automatically authorized if no authorization policy is assigned to the service.

Figure 15.3. Authorization in Zorp