Zorp can authenticate and authorize access to the services. The aim of authentication is to identify the user and the associated group memberships. When the client initiates a connection, it actually tries to use a service. Zorp checks if an authentication policy is associated to the service. If an authentication policy is present, Zorp contacts the authentication provider specified in the authentication policy. The type of authentication (the authentication class used, e.g., InbandAuthentication) is also specified in the authentication policy. The authentication provider connects to an authentication backend (e.g., a user database) to perform the authentication of the client - Zorp itself does not directly communicate with the database.

If the authentication is successful, the client is verified if it is allowed to access the service (by evaluating the authorization policy and the identity and group memberships of the client). 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.

Currently only one authentication provider, the () is available via the ZAS2AuthenticationBackend class. Authentication providers are actually configured instances of the authentication backends, and it is independent from the database that the backend connects to. The authentication backend is that ties the authentication provider to the server storing the user data. For details on using , see the Connection authentication and authorization chapter of the Zorp Administrator's Guide.

The aim of authentication is to identify the user and resolve group memberships. The results are stored in the in the auth_user and auth_groups attributes of the session object. Note that apart from the information required for authentication, Zorp also sends session information (e.g., the IP address of the client) to the authentication provider.

Zorp provides the following authentication classes:

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.

Each service can use an authorization policy to determine whether a client is allowed to access the service. If the authorization is based on the identity of the client, it takes place only after a successful authentication - identity-based authorization can be performed only if the client's identity is known and has been verified. The actual authorization is performed by Zorp, based on the authentication information received from or extracted from the protocol.

Zorp provides the following authorization classes: