1 Grid security Services and Support Vincenzo Ciaschini, INFN CNAF V INFN-GRID workshop 18-20/12/2006

2 Index Basic services  VOMS Security in grid services  WMS, DM, IS, etc… Forthcoming services  G-PBox, StoRM, glExec

3 VOMS

4 What is VOMS VOMS is an X.509 Attribute Authority with special support for grids.  Adds groups and roles.  Adds Attribute Certificates (ACs) directly in the user proxy.  Used via voms-proxy-init command.  Compatible with grid-proxy-init

5 Current status (voms) Server version is the latest version in production.  It can generate proxy certificates for globus 2 and 3.  Does not support globus 4. LDAP server have been turned off.

6 Current status (voms) Many VOs only hosted at CERN.  cms, atlas, alice, lhcb, etc…  No replication -- CERN team not interested in doing it. Other VOs at CNAF  Infngrid, etc..  Available for replication

7 Current status (voms) Stability  VOMS at CERN highly unstable CERN Oracle sometimes goes into ‘kernel panic’. CERN Oracle also gets in other non-working states. No replication means no one can create a proxy.

8 Current status (voms) Old (Non INFN-developed) voms-admin may leaks memory.  Only happens at the CERN installation.  Not reproducible anywhere else.  Not interesting: voms-admin 2.0 will be out in january and is a rewrite of voms-admin 1.x Status  Tested by EGEE testing team.  Core considered stable by gLite.

9 In Certification (voms) Voms version is in certification.  New features breakout: Generic attributes Host certificates in AC GT4 support Correct Java APIs Several bug fixes

10 In Certification (voms) Additional features:  Support for generic attributes Couples (name, value) Requested by: LHCb, Atlas (user afs identity) Support for shibboleth integration Other middleware: DGAS (user LHR) Examples:  (parentOrganization, INFN CNAF)  (guarantor, Andrea Sciaba)  (user, vciaschi) Deprecates capabilities.

11 In Certification (voms) Additional features  VOMS certificate included in the voms proxy instead than distributed in vomsdir. Requested by SA1 to ease management.  VOMS certificates are needed for proxy verification, but change rapidly (once a year)  Current update procedures are not up to this for several VOs. Transparent to the user.

12 In Certification (voms) Additional features  Support for GT4 Needed for interoperability and usage with many non-gLite grids. Native globus version of gLite 3.1 INCOMPATIBLE proxy format with GT3  Last verified with GT and GT  However, you may still generate GT2 proxies. They are compatible with pretty much anything.

13 In Certification (voms) Additional features  Corrected AC verification in Java APIs. Previous versions would consider invalid ACs as valid.  Several bug fixes See bDevelopment for details. bDevelopment

14 Forthcoming (voms) Voms-admin version 2.0  Easier, more stable and more maintainable administration interface.  Would include conformance to JSPG requirements.  Would allow user to request inclusion in specific groups/ownership of specific roles.  Developed by INFN

15 Voms-admin screenshot

16 Forthcoming (voms) Java voms-proxy-init.  Create proxies from java applications. Requested by several applications. Logging to syslog  Requested by operational security. Multiple certificates for each user  Solves problems with CA rollovers.

17 Forthcoming (voms) SAML support  VOMS will generate standard SAML AttributeAssertions  Useful to make VOMS contactable by Web Services  AttributeAssertions will be usable independently from the user’s credentials.  Development under the OMII-EU project

18 Forthcoming VOMS VOMS voms-proxy-init –voms vo Proxy +AC SAML Attribute Assertion GSI Auth. Web Service WSDL SSL Auth AC SAML Attribute Assertion

19 Forthcoming (voms) Shibboleth interoperability.  Attributes coming from a Shibboleth IdP can be inserted directly into a VOMS proxy.  Allows users having a Shibboleth account to use that information also in their grid account.  In conjunction with SLCS, or with an already existing certificate, allows direct usage of the grid from a successful Shibboleth authentication. SLCS is not in IGTF, but will be submitted for evaluation there. Note:  Shibboleth is the state of the art for web authorization.  Very good support for federations.  Can be used to access non grid-resources E.g: medical databases  But a component like SLCS or another certificate is necessary for job submission on the grid.

20 gLite Middleware (in production)

21 Workload Management System DGAS Data Management RGMA Computing Element

22 Workload Management System (current) User Interface:  The user interface extracts just the VO name and the first FQAN and puts them in the JDL. Multiple VOs are ignored. Multiple groups/roles are ignored. Matchmaking:  Ignores the extension in the proxy.  Only uses the information in the JDL. Implies the use of only the first FQAN from the first VO.

23 Workload Management System (future) No changes

24 DGAS DGAS:  VOMS groups and roles are used for access authorization. Multiple VOs are ignored. Multiple groups/roles are considered.  Production in INFNGrid, not in gLite!  No changes envisioned in the future

25 Data Management (current) VO and group/role information from VOMS certificates are used to decide which ACL and which channels to use.  True for: Fireman, LFC, Hydra, FTS. glite-transfer-* commands, lfc-* commands, dpm-* commands, etc…

26 Data Management (current) Within FTS, VOMS groups and roles are used to authorize job start and cancellation and channel manipulation.  Jobs for FTS are file transfers. DPM  Uses SRMv2.2, but depends on LFC for ACLs.  Is capable of managing only one FQAN.

27 Data Management (future) Probably most complete support up-to- date, but…  Default gLite configuration is not using it. Still using gridmap files!  Dedicated effort to change the default gLite configuration

28 Data Management (future) Support for VOMS credentials also in Castor and dCache  For dCache, support is already present in its gPlazma cell in the newest releases.  For Castor: “VOMS is supported – whatever that means.”

29 RGMA (current) “Currently, we have no authorization”!

30 RGMA (future) RGMA plans to support group/roles for authorization “early next year.”

31 Computing Element (current) LCG CE and gLite CE are based on LCAS/LCMAPS for authorization.  LCAS/LCMAPS respectively authorize and map users depending on local policies. They have full support of VOMS groups/roles, and even of multiple ACs (multiple VOs) in the user credentials.

32 Computer Element (forthcoming) CREAM CE  Uses the grid Java Authorization Framework (gJAF) Full support of groups/roles

33 gLite Middleware (forthcoming)

34 Forthcoming middleware G-PBox StoRM glexec

35 What is G-PBox It is an highly distributed policy management and evaluation framework  Policies are necessary in any grid environment. It is the natural complement of VOMS  VOMS issues attributes  G-PBox uses them for policy evaluation VOMS (Attribute Authority) VOMS (Attribute Authority) G-PBox (Policy System) G-PBox (Policy System) VO Admin.

36 One G-PBox (at least) for each VOOne G-PBox (at least) for each VO One G-PBox for a Site or a brunch of SitesOne G-PBox for a Site or a brunch of Sites PBox PBoxPBox G-PBoxes are the basic elements of G-PBox They originate and distribute policies created by VO and Site admin They originate and distribute policies created by VO and Site admin They evaluate requests from Resources/Services contacted by User They evaluate requests from Resources/Services contacted by User What is G-PBox

37 Site Site SiteSite GRID(NorduGrid) GRID(INFNGrid) VO PBox PBox PBox PBoxPBoxPBoxPBox PBox PBoxPBox SubFARM SubFARM SubFARM

38 Credentials usage G-PBox fully supports policies which include references to VOMS groups/roles.  This implies that all services using it would automagically fully support VOMS. Fully tested by developers and (rudimentally) by several VOs.  G-PBox compliant WMS and CE.

39 StoRM introduction StoRM is a storage resource manager for disk based storage systems.  It implements the SRM interface version 2.2.  StoRM is designed to support guaranteed space reservation and direct access (native POSIX I/O call), as well as other standard libraries (like RFIO).  StoRM take advantage from high performance parallel file systems. Also standard POSIX file systems are supported (XFS, ext3, …).  A modular architecture decouples StoRM logic from the supported file system.  Strong security framework with VOMS support.

40 StoRM Security Aspects 1.User perform srmPrepareToGet 2.StoRM verifies if the principal holds a valid proxy certificate and delegates the external policy decision point to validate the request. 3.StoRM then queries the Authorization Sources to verify if the user can perform the specified operation on the SURL 4.StoRM queries LCMAPS to obtain local user account corresponding to the grid identity of the requestor 1.Using LCAS/LCMAPS for authorization implies the same capabilities of LCAS/LCMAPS in voms credential management. 5.Physical file name derives by SURL and user attributes (Virtual organization name space) 6.The file system wrapper enforces permissions by setting a new ACL on the physical file. 7.The user job can be executed into the worker node 8.The application can perform a standard POSIX call to access the file into/from the storage system.

41 glexec glexec changes the credentials and user mapping of a job  Changes the credentials and than does exec() The calling process does not exist anymore.  I.e: user ‘/C=IT/O=my/CN=some user’ mapped to myvo001 can become: /C=IT/O=my/CN=other user’ mapped to myvo002  Uses LCAS/LCMAPS.

42 Thanks to A.Frohner, S.Fisher, A.Ferraro, Y.Demchenko, O.Koeroo, M.Sgaravatto, L.Magnoni for the info and some slides. All errors are only mine 