Services Security A. Casajus R. Graciani

12/12/ Overview DIRAC Security Infrastructure HSGE Transport Authentication Authorization DIRAC Authorization scheme DIRAC Portals DIRAC Transfers Relation with VOMS

12/12/ DIRAC Security Infrastructure Based on: –Trusted “Certification Authorities”, CA, for Authentication. –“Virtual Organizations”, VO, for Authorization. We want to skip globus and use directly OpenSSL to minimize dependencies Dirac applications use grid proxies to connect to services. –Based on x509 certificates understood by OpenSSL

12/12/ DIRAC Security Infrastructure What the user needs: –Certificate and key signed by a CA and accepted by VO –Up-to-date CAs and CRLs –Being able to generate a Grid Proxy (grid-proxy-init) What the server needs: –Certificate and key signed by a CA –Up-to-date CAs and CRLs The server is also authenticated by the client.

12/12/ Dependencies DIRAC Security Infrastructure relies on: –pyOpenSSL. Python module encapsulating some of the native OpenSSL functionalities. –OpenSSL. Open source full-featured toolkit implementing Secure Sockets Layer (SSL v2/3 ) and Transport Layer Security (TLS). pyOpenSSL wraps all needed OpenSSL calls in a simple python API. Some extensions were implemented. OpenSSL handles all underlying authentication except grid proxies.

12/12/ XML-RPC way Python provides XML-RPC implementation ready to use over a non- secure channel. Secure connection support provided by python is very limited. Would be nice to mix OpenSSL, pyOpenSSL and python’s XML-RPC to provide an easy gateway to secure XML- RPC.

12/12/ HSGE Transport HTTP + SSL + GRID + Extended transport layer HSGE wraps together all nasty ssl code, authorization and authentication mechanisms under simple calls. Uses XML-RPC to perform remote calls over HTTP/HTTPS depending on the URL automatically. unsecureClient = HSGEClient( “ ) unsecureClient.get( “ConfigurationService”, “List” ) secureClient = HSGEClient( “ ) secureClient.rescheduleJob( iJobID )

12/12/ HSGE Transport

12/12/ HSGE Transport Supports >200 pet/s,  10 times more than other implementations tested (Apache + mod_ssl, GridSite). From the client point of view is used exactly the same way as native XML-RPC. From the server point of view: –By changing the HSGE server object petitions can be handled in secured or unsecured way. Developer’s code remains the same. class FakeServiceHandler ( HSGERequestHandler ): def export_fakeMethod( self, someArg, someOtherArg ): doSomething() oSecureServer = HSGEServer( ( “”, iPort ), FakeServiceHandler, “ServiceName” ) oSecureServer.serve_forever() oUnsecureServer = HSGEUnsecureServer( ( “”, iPort ), FakeServiceHandler, “ServiceName” ) oUnsecureServer.serve_forever() –Authentication and first level authorization are hidden from developer’s server code.

12/12/ Authentication Official OpenSSL does not support grid proxies. HSGE OpenSSL version supports standard X509 certificates and grid proxies as well. HSGE uses ssl sessions (lifetime defined as a parameter) for each client. Just one handshake for multiple calls.

12/12/ Authentication Grid proxies chain are tested until a valid CA is found to ensure their validity Each side of the channel authenticates the other one (server  client and client  server). –All DIRAC secure clients and servers need valid and unexpired certificates.

12/12/ Authorization The HSGE authorization is done in a per method basis. HSGE Server side verifies user’s DN to be in an authorized list of users (role) for the method called. User defines witch role wants to use for dirac application. #~> dirac-role.py lhcb_user If the user does not specify a role lhcb_user is used as default. User’s DN and role are available to server methods. –For instance, lhcb_user is authorized to access a job Matching method, but the JobMatcher will only return jobs that belong to the given DN (or role).

12/12/ DIRAC Authorization scheme Each server has authorized roles defined via local or remote configuration for each method it exports. [TestServiceAuthorization] Default = lhcb_user exampleMethod1 = lhcb_user, lhcb_prod, lhcb_admin exampleMethod2 = lhcb_prod, lhcb_admin exampleMethod3 = lhcb_admin Clients include their role on each XML-RPC query: HSGE code checks if the user belongs to the role sent and if the role is allowed to perform the call. User’s DN is taken from the proxy or certificate.

12/12/ DIRAC Authorization scheme List of roles (can be extended): –lhcb_user: explicit DN list of all lhcb recognized users. Must be kept in sync with VO. –lhcb_prod: explicit DN list of production managers, responsible for “production” type activities. –lhcb_admin: explicit DN list of users with DIRAC administrative privileges. Roles are defined in section [DiracRoles] [DiracRoles] lhcb_user = FakeDN1 lhcb_user += FakeDN2 … lhcb_prod = FakeDN3 …

12/12/ Portal DIRAC Portals Portals are connection redirectors. Clients can connect a portal, and it will forward the connection to the destination server. Each portal can redirect to many services. Client Service 1 Client Service 1

12/12/ DIRAC Portals Redirection is based on the URL –Portal URL + Service Name  Two kind of portals –Secure portals Programmed in python + HSGE Can redirect to either secure and unsecure services –Unsecure portals Also programmed in PHP + web server Can only redirect to unsecure services

12/12/ Advantages of DIRAC Portals Single entry point for all services Benefits of secure portals –Reduce number of ssl authentications Server receives handshakes only from portals. One client has just to handshake once for all petitions though the portal.

12/12/ DIRAC portals Client: Agent, Job Wrapper, Production Manager,… HSGE: DIRAC Portal Server: Configuration Service SSL Negotiation Client Query Server Response Connection request SSL Negotiation Client Query Server Response Connection request

12/12/ Security in Secure DIRAC Portals Secure portals need a valid certificate. Act as clients and servers. Final server needs to know who are the recognized portals. Portals authenticate the client and services authorize the call.

12/12/ Server: WMS Job Receiver Service Redirection HSGE: DIRAC 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 Portal HSGE: DIRAC Portal Server: Configuration Service Server: WMS Job Receiver Server: WMS Job Matcher Server: Configuration Service Server: Configuration Service User Cert. Portal Cert.

12/12/ HSGE Transfers HSGE also allows to transfer files from and to servers. Uses the same authentication + authorization as normal HSGE. Transfer information is sent via XML-RPC using HSGE. Once a transfer is accepted (DIRAC authorization), data is sent in binary format through the same connection.

12/12/ HSGE Transfers To enable transfers developers must code some specific callbacks. Services can serve normal XML-RPC petitions and transfer petitions. Developers simply have to code whatever callbacks they need in the request handler. In a “put” transfer (client  server) needed callbacks are: putFileHSGE( self, sID, sFilename ) receiveFile( self, stFileData ) In a “get” transfer (server  client) needed callbacks are: getFileHSGE( self, sID, sFilename ) sendFile( self, stFileData ) errorSendingFile( self, stFileData, dErrorInfo )

12/12/ HSGE Transfers Data is sent and received using helper functions: Client Example oClient = HSGETransferClient( “ % iPort ) If oClient.putFile( “/etc/motd”, sJobID, “motd” )[ ‘Status’ ] == “Error”: processError() Server Example: Class ExampleRH (HSGERequestHandler): def putFileHSGE( self, sID, sFilename ): return S_OK() def receiveFile( self, stFileData ): sData = “dummy” while len( sData ) > 0: self.doSomething( sData ) sData = self._getDataPacket() oServer = HSGEServer( ( “”, iPort ), ExampleRH, “ExampleTransfer” ) oServer.serve_forever()

12/12/ Relation with VOMS Daily update from ldap VO server. lhcb_user role is updated from the VO server (ldap://grid-vo.nikhef.nl/ou=lcg1,o=lhcb,dc=eu- datagrid,dc=org). Things to do: –Retrieve short username from VOMS –Associate DIRAC roles to VOMS groups

12/12/ To be done DIRAC roles: –User –Group –Admin DIRAC groups: –Lhcb_user –Lhcb_prod –Lhcb_admin –Lhcb_data –… Use VOMS and VOMS proxy to associate users to groups. Lhcb user Lhcb prod Lhcb admin Lhcb data UserX GroupXX adminX