Difference: WMProxyDocumentation (3 vs. 4)

0.1 Architecture

• The Fast CGI module provides Common Gateway Interface (CGI) functionality with some other specific features. The most important advantage of Fast CGI is its performance and persistence. Fast CGI can be seen as a new implementation of CGI, designed to overcome CGI's performance problems. The major implementation differences are:
  • Fast CGI processes are persistent: Fast CGI applications are able to serve multiple requests
  • Application instances are spawned/killed dynamically according to demand
  • Fast CGI protocol multiplexes the environment information, standard input, output, and error over a single full-duplex connection.

WMProxy in its default configuration is run as a dynamic Fast CGI application in order to take full advantage of its capacity to accommodate request loads. However, it can be run in any of the available Fast CGI modalities. WMProxy is implemented as a single-threaded application thus ensuring more reliability and robustness than multi-threaded applications; thanks to the Fast CGI process manager the web server maintains a pool of processes that allow improving performances as generally done through multi-threaded application.

• Grid Site provides a module extending the Apache webserver for use within Grid frameworks by adding support for Grid security credentials such as Grid Security Infrastructure (GSI) and Virtual Organization Membership Service (VOMS), and file transfer over HTTPS. It also provides a library for handling Grid Access Control Lists (GACL).

The integration of the WMProxy within the WMS is shown in Figure 1. WMProxy provides a core module performing validation, conversion, environment preparation and information logging for each incoming request, before delivering it to the Workload Manager (WM). WM is the core component of the WMS taking the appropriate actions to satisfy incoming requests. Communication between the WMProxy and the WM occurs through a thread-safe, file-system based queue. The LBProxy, which is used as a state storage of active jobs, is the only external service with which the WMProxy interacts. The LBProxy service provides an optimized access to the Logging and Bookkeeping Service (LB). Other relevant information about processed jobs/requests are stored in the local file system in a reserved area managed by the WMS.

0.2 Security, AuthN & AuthZ

Message exchange between client and server is performed with SOAP/HTTPS.

Authentication of the requesting user is done through the X.509 proxy certificate signed by a trusted Certification Authority (CA), which guarantees that the exposed public key is really owned by the user. The authentication process is handled by the Apache HTTP server by means of the SSL and Grid Site modules. The authenticated request together with information about the checked credential (e.g. expiration time, VOMS extensions), are then passed to WMProxy within the CGI environment. WMProxy does not need to directly manipulate Grid credentials in this phase.

Authorization is implemented through the Grid Access Control List (GACL) library, which is provided by Grid Site for manipulating Access Control List (ACL) files. Authorization can be either Fully Qualified Attribute Name (FQAN) (coarse-grained) or Distinguished Name (DN) based (fine-grained) according to the type of proxy presented by the client.

There are two authorization steps that are performed for an incoming request within the WMProxy:

• Determine whether the requesting user is authorized to use the WMS services.
• Determine whether the requesting user is either the owner of the job or has permissions to manage it. (This step is only performed for operations directly related to a given job)

0.3 Credentials Delegation

0.3.1 Delegation Process

0.3.2 Credentials Renewal