1. GRID Security & DIRAC A. Casajus R. Graciani A. Tsaregorodtsev

2. 2 Overview Grid Security Infrastructure OpenSSL/TLSlite XML-RPC Authentication Authorization DIRAC web portals Running Jobs Summary

3. 3 GSI: CA’s, Certificates, Proxies Based on: –trusted “Certification Authorities”, CA, (for Authentication), + –“Virtual Organizations”, VO, (for Authorization). Users get a pair certificate + private key, signed by a CA and accepted by a VO. GRID applications use a “Proxy”, a self sign certificated with limited time validity. GRID Services also have a certificate + private key pair (signed by a CA) that allows them to be Authenticated by the Clients (a User or other Service) –Based on x509 certificates, understood by openSSL –Want to skip globus, and go directly to openSSL

4. 4 OpenSSL/TLS Lite The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols as well as a full-strength general purpose cryptography library. Open SourceSecure Sockets LayerTransport Layer Security –Latest version: »openssl-0.9.7f.tar.gz (3 MB)openssl-0.9.7f.tar.gz TLS Lite is a free python library for SSL/TLS. It is pure Python, however it can access OpenSSL, cryptlib, pycrypto, and GMPY for faster crypto operations.TLS LitePythonOpenSSLcryptlibpycrypto GMPY –Latest version: »tlslite-0.3.8.tar.gz (0.6 MB)tlslite-0.3.8.tar.gz

5. 5 XML-RPC Python provides XML-RPC server and client implementations ready to use (over HTTP). However HTTPS native support provided by python is very limited. pyOpenSSL is an python extension supporting further SSL functionality. Further extension is needed to handle: –CA directories. –GRID proxies. –Multi-thread servers. –Maker use of SSL sessions to reduce handshake overheads.

6. 6 HSGE Transport HTTP + SSL + GRID + Extended transport layer has been implemented and tested using pyOpenSSL. Supports >200 pet/s,  10 times more than other implementation tested (Apache + mod_ssl, GridSite). It allows performing implementation of DIRAC services. Adds extra dependencies on SSL and CRYPTO libraries, and GLIBC. OK for Servers. For DIRAC clients TLS Lite can provide a pure python implementation (to be tested).

7. 7 Authentication HSGE servers and clients can make use of standard GRID security infrastructure for CA’s and CRL’s. Up-to-date versions of CA’s and CRL’s may also be sent with DIRAC (for non-LCG sites, or to include a DIRAC specific CA). Mutual authentication (server -> client and client -> server) should be the default. All DIRAC client (and servers) will need valid (and up-to-date) certificates.

8. 8 Authorization Base on 3 components: –Add client DN and role as first parameter to XML- RPC query after authentication. –Use a Central Authorization Service (backup by VOMS for instance) to define which users (or group of users) are allowed to take redefined roles. –Server Handlers may also make use of DN while processing the request. Authenticated connections may pass a DN. –user DN if the client is a DIRAC USER, or, –a delegate user DN if the client is another DIRAC SERVER.

9. 9 DIRAC Authorization scheme (I) Allow unsecured Servers (ie read-only interface to Configuration Service). Based on DN/role pairs for each Server Method: –Servers define via Configuration (either local or central), which roles are allowed to access a given method: [ServiceNameAuthorization] Default=admin Method1 = any Method2 = user Method3 = production, admin (Method4 = admin) Method5 = user –Clients include their DN/role on each XML-RPC query: »Client code must check the requested role. »Server code must check both role and access to method. »Appropriated errors must be issued. –Servers may make use of the DN/role in the request: »All users are authorized to get a job Matching, but the JobMatcher will only return jobs that belong to the given DN (or role).

10. 10 DIRAC Authorization scheme (II) List of roles (can be extended): –any: “key word” used for non-authenticated connections or non-lhcb certificates. –user|lhcb: explicit DN list of all lhcb recognized users. Must be kept in synch with VO. –production: explicit DN list of production managers, responsible for “production” type activities. –admin: explicit DN list of users with DIRAC administrative privileges. Using (a second?) Configuration Service: –Section DiracRoles, with roles as Options and DN’s as values. –Need lists in the Configuration Service. –Make use of += to generate a list for a given option.(easier to read?). Can be regularly updated from VOMS.

11. 11 DIRAC web portals (I) Aim: provide access to all DIRAC services through an unique entry point. Incorporate HGSE as transport layer. –https://lhcb01.pic.es[:DIRAC_PORT]/ConfigurationService  https://lxgate14.cern.ch:9130 | https://lhcb01.pic.es:9130|... –https://lhcb01.pic.es[:DIRAC_PORT]/JobMatcher  https://lxgate14.cern.ch: | https:// –… Redirection is active and dynamic: –Checks client DN (provided as query parameter). –Chooses appropriated destination Server (may include load balance and backup). –Can be changed dynamically. Clients keep SSL session with Portal. Portal keeps SSL sessions with Servers. A DIRAC Portal running on the Site head-node (or Service CE) reduces need of outbound connectivity from the WN.

12. 12 DIRAC web portals (II) Client: Agent, Job Wrapper, Production Manager,… HSGE: DIRAC web Portal Server: Configuration Service SSL Negotiation Client Query Server Response Connection request SSL Negotiation Client Query Server Response Connection request

13. 13 Server: WMS Job Receiver Service Redirection + M/S HSGE: DIRAC web Portal Server: Monitoring Service Server: WMS Job Matcher Client: Agent, Job Wrapper, Production Manager,… Client: Agent, Job Wrapper, Production Manager, … Client: Agent, Job Wrapper, Production Manager, … HSGE: DIRAC web Portal HSGE: DIRAC web Portal Server: Configuration Service Server: WMS Job Receiver Server: WMS Job Matcher Server: Configuration Service Server: Configuration Service User Cert. Portal Cert.

14. 14 Job Submission USER jobs: –GANGA. –Others. Group jobs: –Physics groups activities. –Calibration, Alignment. Production Jobs: –Simulation. –Data Processing (Merging, Stripping, Reprocessing,…). »Step 1: DIRAC. »Step 2: Computing Resource.

15. 15 USER Jobs, GANGA Security makes it difficult to move around user proxies. USER jobs are submitted and run using the user certificate. Hide details from user but make them aware of the system complexity. –Define task. –Introduce task in DIRAC WMS. –Request Computing Resources for the task (Local PC, Local Batch queue, GRID). –Get back the Results. All Steps are done in the same environment (GANGA) but the user must be aware of all of them.

16. 16 Group Jobs GANGA They are a special case of USER Jobs. Use Roles so DIRAC can identify them. How to handle priorities and quotas in this scheme?

17. 17 Summary Use HGSE as transport layer for XML-RPC (including the user DN/role as extra parameter). Use pyOpenSSL (C based) for Servers and TLS Lite (python based) for Clients. Extend Configuration Service to handle Authorization scheme and roles. User pilot jobs are submited by the user (GANGA) to LCG.

18. 18 Open Questions Is this the simplest complete approach? Do we need | want a DIRAC CA? What is behind the Authorization Service (VOMS) ?

19. 19 User/Group Jobs GANGA (II) Computing Resources are allocated by a General LHCb User (“LHCb Analysis” or “LHCb Production”). Jobs are run on behalf of the user. LHCb gains full control of allocated resources: –Many (different) user jobs can be executed on a single job. –DIRAC can set quotas and priorities for different activities. How to make the Services aware of the USER identity? –File property on SE and FC To ensure traceability: –User job requests are signed by user certificate –Can this signature be used for FC operations Full LHCb can be excluded from a site (or many sites) due to a single user: –Strong limitation to user actions within this framework.