Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 40 to 40 | ||||||||
| ||||||||
Changed: | ||||||||
< < | re | |||||||
> > | 0.1 ArchitectureTo adhere to the SOA model, WMProxy has been designed and implemented as a Simple Object Access Protocol (SOAP) Web service. The interface is described through the Web Service Description Language (WSDL). The WSDL file was written following the Web Services Interoperability Basic Profile (WS-I Basic Profile). This profile defines a set of Web Services specifications that promote interoperability. The WMProxy service runs in an Apache container extended with Fast CGI and Grid Site modules.
![]() 0.2 Security, AuthN & AuthZMessage 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:
0.3 Credentials Delegation0.3.1 Delegation ProcessThe delegation is the process used to transfer rights and privileges to another party. Since the WMProxy and the WMS when providing some services need to interact with other services, operating on behalf of the user, a delegation process is needed to transfer client proxy credentials to the server host. The delegation service is provided through a port type whose description is imported into the WMProxy WSDL file from the gLite common delegation WSDL file. Delegated credentials are uniquely identified by the association of the delegation identifier, provided by user, and the user’s DN within the credentials. Multiple delegations of the same proxy credential are allowed with different delegation identifiers; however, it is recommended to do it once at the beginning of the working session and reuse the same delegation identifier, as delegation process is generally time-consuming. The WMProxy holds a cache of the delegated proxies, which is purged periodically from the expired credentials; upon a submission request the service performs a mapping between the incoming job and a proxy in its cache according to the requesting user DN and the specified delegation identifier. From that point on, each operation performed for that job is done using the credential associated to it in this way.![]() 0.3.2 Credentials RenewalThe User can store a long-lived certificate that can be used by the WMS in order to renew the lifetime of a standard user certificate proxy (usually valid only for 12 hours). Long-running jobs may run into this limit and fail due to expioration of user proxy. WMProxy can automatically request the registration for renewing the proxy certificate sent by the user. This is done through the attribute "MyProxyServer" inside the submitting JDL. When a Proxy Renewal Registration is requested for a certain Job, the WMProxy registers it to the proxy renewal. From that moment on, credentials for such jobs are granted by renewed certificate credentials. Actually all jobs that uses the same credentials links to only one renewed certificate. | |||||||
-- FabioCapannini - 2011-11-04 | ||||||||
Added: | ||||||||
> > |
|