gLite Security Overview Christoph Witzig, SWITCH (christoph.witzig@switch.ch) MWSG - March 30, 2009

On-going work in EGEE-III New Authorization Service Outlook Outline Security overview On-going work in EGEE-III New Authorization Service Outlook MWSG Zurich, 30.3.2009

EGEE Security Organization JRA1 / Security Middleware Security Group Grid Security Vulnerability Group Joint Security Policy Group EUGridPMA Operational Security Coordination Team http://www.eu-egee.org/security/ Security in EGEE-III: 440 PM MWSG Zurich, 30.3.2009

Security Layout MWSG Zurich, 30.3.2009

Components VOMS MyProxy BDII Job management Data management Proxy certificates with VOMS AC MyProxy BDII Job management WMS L&B CE: lcg-CE, CREAM LRMS: pbs/torque, LSF, SGE WN Data management DPM, CASTOR, dCache, STORM LFC, Hydra gridFTP, FTS MWSG Zurich, 30.3.2009

CE (1/2) MWSG Zurich, 30.3.2009

CE (2/2) MWSG Zurich, 30.3.2009

Decoupling FQANs and Shares (1/3) Mapping FQAN --> GID --> share links the FQAN to the scheduling Sites tend to decide share between VOs VOs tend to decide share between types of jobs (e.g. FQANs) Sites need to be reconfigured by site admins if VOs wants to change the relative share of the FQANs MWSG Zurich, 30.3.2009

Decoupling FQANs and Shares (2/3) MWSG Zurich, 30.3.2009

Decoupling FQANs and Shares (3/3) Status: Debated in the past Current status: deferred (TMB: March 2008) Main argument: Cost - benefit given pilot jobs are a fact MWSG Zurich, 30.3.2009

Data Management DPM, LFC: Hydra Mapping of DN/FQAN to virtual UID/GIDs which determine access Hydra Stores pieces of keys, which were used to encrypt data, and their ACLs Interface between DPM and DICOM Metadata catalog AMGA Used by biomed MWSG Zurich, 30.3.2009

On-going work in EGEE-III Security overview On-going work in EGEE-III New Authorization Service Outlook MWSG Zurich, 30.3.2009

Current Issues Authentication: Authorization Isolation and sandboxing Proxy certificates Pseudonymity and anonymity Short-lived certificates (SLCS services) Authorization New authorization service Other authZ issues Isolation and sandboxing Connectivity of WN to internet No work planned Storage (see Akos’s talk) DPM security model extended to CASTOR Quotas for DPM (?) Simple command line tools See: https://edms.cern.ch/document/935451/1 MWSG Zurich, 30.3.2009

authN: Proxies Lifetime issue: VOMS-enabled keystore would be nice Proxies cannot be revoked --> short lifetime Short lifetime --> renewal Renewal service in WMS: interacts with MyProxy and VOMS There were software issues in the past - fixed now Consequence: Some VOs had to extend lifetime in the past Lifetime should be made shorter now VOMS-enabled keystore would be nice MWSG Zurich, 30.3.2009

authN: Pseudonymity and Anonymity Required by EU laws No work in EGEE-III Pseudonymity service exists MWSG Zurich, 30.3.2009

authN: SLCS Services Offer potential for distributing certificates to user in an easy way based Several SLCS are either in operation or planned SWITCH DFN Netherlands / northern countries Use coupled to national AAIs Quality depends on AAI MWSG Zurich, 30.3.2009

Authorization Development of new authorization service (see later) Job and data management use the same primary FQAN Plan to allow the user to specifiy data management FQAN Will be added to CREAM Revised FQAN syntax Originally planned to introduce in late 2008 New: towards end of EGEE-III Most significant match in LCMAPS Removes ambiguity of LCMAPS mapping Coupled with “consider only one share per CE” by WMS will make user mapping consistent between WMS and CE MWSG Zurich, 30.3.2009

Simple Command Line Tools Jointly defined with OSG Different priorities for OSG / EGEE authz_check / cred_mapping Command line evaluation of authz decisions Will be available with new authZ service ban_user: Command line banning of users task_removal: Job cache in blah - fall 2009 check_connection Simple debugging tool for openssl - fall 2009 MWSG Zurich, 30.3.2009

New Authorization Service Security overview On-going work in EGEE-III New Authorization Service Outlook MWSG Zurich, 30.3.2009

Outline Introduction Short Description of the Service Deployment Proposal Policy for Global Banning MWSG Zurich, 30.3.2009

Use-Case: Multi-User Pilot Jobs Short-term solution: SCAS MWSG Zurich, 30.3.2009

Institutions Involved CNAF HIP NIKHEF SWITCH Deployment plan Devised together with SA1 / SA3 Reviewed and endorsed by TMB Note abbreviation: authZ = authorization MWSG Zurich, 30.3.2009

The Plan Starting point: authorization study in EGEE-II Identified need for consistent authorization in gLite authZ service part of the DoW for EGEE-III Based on input from SA1/SA3 decided: EGEE-III year 1: development of service EGEE-III year 2: deployment of service Reason: Service should be deployed within EGEE-III Current status: Service is expected to enter certification in first half of April MWSG Zurich, 30.3.2009

Introduction: Which Problems Are We Trying to Solve? Different Services use different authorization mechanisms Some services even use internally more than one authorization framework Site administrators do not have simple debugging tools to check and understand their authorization configuration Site administrators must configure the authorization for each service at their site separately Consequence 1: At a site, there is no single point to ban users/groups of users for the entire site Consequence 2: many site administrators don’t know how to ban users There should be a command line tool for banning and un-banning users at a site MWSG Zurich, 30.3.2009

Introduction: Which Problems Are We Trying to Solve? There is no central grid-wide banning list to be used during incidents Consequence: Urgent ban cannot be taken for granted during incidents No monitoring on authorization decisions MWSG Zurich, 30.3.2009

Introduction: Benefits of the Authorization Service Main benefit within EGEE-III: Addressing the above list of short-comings There are other benefits: see appendix MWSG Zurich, 30.3.2009

Short Description of the Service Outline Introduction Short Description of the Service Deployment Proposal Policy for Global Banning MWSG Zurich, 30.3.2009

Service Components Initial rules: Banning unbanning Pilot job Initial default deployment: All components on one host Administration Point: Formulating the rules through command line interface and/or file-based input Decision Point: Evaluating a request from a client based on the rules Enforcement Point: Thin client part and server part: all complexity in server part Runtime Execution Environment: Under which env. must I run? (UID, GID) MWSG Zurich, 30.3.2009

On the CE MWSG Zurich, 30.3.2009

Features (1/2) Multi-plattform support Easy to install XACML-based SL4/5, RH 4/5, debian Easy to install tar -zxf XACML-based But XACML hidden from administrator CLI and simplified policy files SAML2-XACML2 profile between PEP and PDP Support for SAML (but not [yet] used in EGEE) Use of OpenSAML / OpenWS Jetty JBossCache MWSG Zurich, 30.3.2009

Features (2/2) Thin PEP client No dependencies on WN Adding other language bindings is easy Easy to integrate into other services Easy CLI interface and consistent logging Nagios plug-ins provided MWSG Zurich, 30.3.2009

Outline Deployment Plan Introduction Short Description of the Service Policy for Global Banning MWSG Zurich, 30.3.2009

Deployment Plan (1/3) Adoption during EGEE-III Deployment during MWSG Zurich, 30.3.2009

Deployment Plan (2/3) Guiding Principle: No big bang but gradually increasing use of authZ service through six self-contained steps glExec on the WN: Only change on WN is new version of glexec / LCMAPS Use of authZ service is a configuration option Installation of authZ service on one host through YAIM ALL policies are local (i.e. no remote policies) Only banning rules and enforcement of pilot job policy Note: No change to CREAM or lcg-CE (authZ policy only affects pilot jobs) MWSG Zurich, 30.3.2009

Deployment Plan (3/3) Grid-wide banning by OSCT Integration into CREAM OSCT offers centralized banning list to the sites Policy for this list currently under discussion (see section policy for global banning) Integration into CREAM Integration into WMS for authZ MWSG Zurich, 30.3.2009

Alternate Deployment Options (1/4) Flexibility of the service allows different deployment models Default deployment: YAIM supports deployment on one single host Alternate deployment options are initially supported by authZ development team on a case-by-case basis MWSG Zurich, 30.3.2009

Alternate Deployment Options (2/4) Note: no shared filesystem required MWSG Zurich, 30.3.2009

Alternate Deployment Options (3/4) MWSG Zurich, 30.3.2009

Alternate Deployment Options (4/4) MWSG Zurich, 30.3.2009

Policy for Global Banning Outline Introduction Short Description of the Service Deployment Proposal Policy for Global Banning MWSG Zurich, 30.3.2009

Operational Policy Each site manages its own access policies Local site autonomy OSCT operates a central banning service (CBS) Sites SHOULD deploy CBS Sites SHOULD give CBS priority over local policies Sites SHOULD configure CBS so any ban/restore action is active in under 6 hours Time period still under discussion Grid Security Operations MUST inform VO manager whenever user/group access is changed (ban & restore) SHOULD= Obligation with escape clause Inform Grid Security Office. Currently proposed by JSPG Discussions continuing. MWSG Zurich, 30.3.2009

Policy for Global Banning Each site manages its own local access policies to its resources. In addition, Grid security operations SHOULD operate a central banning service. Whenever Grid security operations bans a user or group of users, or restores their access, they MUST inform the appropriate VO Manager. Sites SHOULD deploy this central banning service and give it priority over local policies. The site implementation of the central banning service SHOULD be configured such that any ban or restore action made by Grid security operations is active at the site without a delay of more than 6 hours MWSG Zurich, 30.3.2009

Further Information About the service: General grid security: Other: authZ service design document: https://edms.cern.ch/document/944192/1 Deployment plan: https://edms.cern.ch/document/984088/1 General grid security: Authorization study: https://edms.cern.ch/document/887174/1 gLite security: architecture: https://edms.cern.ch/document/935451/2 Other: Wiki: (just started, so pretty empty right now!) https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework EGEE08 presentations: http://indico.cern.ch/sessionDisplay.py?sessionId=94&confId=32220 http://indico.cern.ch/sessionDisplay.py?sessionId=95&slotId=0&confId=32220 - 2008-09-25 MWSG Zurich, 30.3.2009

Summary MWSG Zurich, 30.3.2009

Summary In EGEE-III: Concentration on maintenance and support Planned to add a few new features Most significant match stuff Different primary FQAN for job and data management New service: authorization service About to enter certification Deployment in a series of self-contained steps MWSG Zurich, 30.3.2009

Backup Slides MWSG Zurich, 30.3.2009

Pattern Matching in gLite C.Witzig, SWITCH Security Architect EGEE christoph.witzig@switch.ch

Why Importance of pattern matching User’s proxy certificate contains an attribute certificate, which contains a list of strings, called “fully qualified attribute names” FAQNs User is authorized at the resource by matching these FQANs against a list of “allowed” FQAN patterns Basis for authorization of users VOMS contains two types of attributes: Group membership - they are always all present in the AC Roles - they user must ask for them to be included at proxy creation time (“voms-proxy-init”) MWSG Zurich, 30.3.2009

What’s the big deal? Quiz: Which FQANs match which patterns? FAQN patterns: /vo1/analysis/* /vo1/ana* /vo1/analysis/role=* FQANs: /vo1/analysis /vo1/analysis/higgs/role=production MWSG Zurich, 30.3.2009

Use of FAQNs and FQAN patterns FQAN pattern matching rules are about to change Consequence of authorization study done at the end of EGEE-II Reason: Many people had difficulty understanding/remembering the rules Answer depended on the order of patterns in gridmapfile Current use: https://edms.cern.ch/document/858263/1 Future use: To be uploaded (by tomorrow) Exact transition date: TBA MWSG Zurich, 30.3.2009

Current Rules MWSG Zurich, 30.3.2009

Syntax and Rules FQAN patterns: /vo1/analysis/hi*/Role=production May contain wildchars Allowed wildchars: ? and * Allowed characters: : [0-9a-zA-Z-_.] /vo1/analysis/hi*/Role=production If string Rule=NULL is present, eliminate it Separate subgroup and role substring and match them separately as substrings (“literal”) /vo1/analysis/hi* /Role=production MWSG Zurich, 30.3.2009

/vo1/* does not match /vo1 /vo1/Role=* does not match /vo1 Pattern FQAN /vo1/analysis/*/Role=pro /vo1/analysis/higgs/Role=pro Yes /vo1/analysis No /vo1/analysis/Role=pro /vo1/an*si? Note: /vo1/* does not match /vo1 /vo1/Role=* does not match /vo1 In order to match an entire VO, you must use two patterns /vo1 /vo1/* MWSG Zurich, 30.3.2009

New Rules MWSG Zurich, 30.3.2009

Syntax FQAN patterns: Allowed FQAN patterns Not allowed FQAN patterns Only * wildchar allowed and it must be at the end of the group/role substring after the trailing / Allowed characters: : [0-9a-zA-Z-_.] Allowed FQAN patterns /vo1/analysis /vo1/analysis/*/Role=production /vo1/*/Role=* Not allowed FQAN patterns /vo1/*/higgs /vo1/*/* /vo1/ana*/higgs /vo1/*/Role=pro* MWSG Zurich, 30.3.2009

Rules Two possible interpretation of * Semantic substitution chosen Object substitution /vo1/* does not match /vo1 /vo1/Role=* does not match /vo Semantic substitution /vo1/* matches /vo1 /vo1/Role=* matches /vo1 Semantic substitution chosen MWSG Zurich, 30.3.2009

/vo1/analysis/*/Role=pro /vo1/analysis/higgs/Role=pro Yes Pattern FQAN /vo1/analysis/*/Role=pro /vo1/analysis/higgs/Role=pro Yes /vo1/analysis No /vo1/analysis/Role=pro /vo1/an*si? Invalid pattern /vo1/* /vo1 /vo1/analysis/higgs /vo1/*/Role=pro /vo1/Role=pro /vo1/Role=* /vo1/*/Role=* MWSG Zurich, 30.3.2009

Note: /vo1/* matches /vo1 /vo1/Role=* matches /vo1 In order to match all groups of an entire VO, you use one pattern /vo1/* In order to match all groups and all roles of an entire VO, you use one pattern /vo1/*/Role=* MWSG Zurich, 30.3.2009

Matching Rule for LCMAPS Current rule: LCMAPS takes first match Consequence: Ordering in gridmapfile matters FQAN = /vo1/analysis /vo1/* .user1 <-- takes first one /vo1/analysis .user2 New rule: LCMAPS takes most significant match Consequence: Ordering in gridmapfile doesn’t matter /vo1/* .user1 /vo1/analysis .user2 <-- takes first one MWSG Zurich, 30.3.2009

Most significant match Question: What is more significant: /vo1/analysis/*/Role=production /vo1/analysis/higgs/Role=* Answer: Group is more significant MWSG Zurich, 30.3.2009

Security Command Line Tools C.Witzig, SWITCH christoph.witzig@switch.ch

A bit of history Goal: A set of useful command line tools for site admins Not user authZ recommendation #3, OSG-EGEE coordination meeting Document at https://edms.cern.ch/document/931846 General remarks: Should be simple Clearly differentiate between commands that Make changes (with option --noaction) Do only return information API specs may have to be modified during implementation Prioritization for EGEE done MWSG Zurich, 30.3.2009

Cmds (1/4) ca_manage: managing CA repository medium priority no time line authz_check: given a credential, return authZ answer (permit/deny/undetermined) priority high to be implemented with new authZ service Reason: non trivial amount of work MWSG Zurich, 30.3.2009

Cmds (2/4) cred_mapping: mapping of a credential to UID/GID(s) Priority: high Two implementation: Simple: Script by M.Litmaath, that returns pool account info given the DN or vice-versa. ML is willing to expand it. Full set with new authZ service cred_cleanup: finding and removing credentials associated with crashed jobs Priority: low Time line: none MWSG Zurich, 30.3.2009

Cmds (3/4) wms_info: returning information about assignment of credentials to shares: Priority: low Time line: none Reason: glite-wms-job-list-match ban_user: banning a user/DN/FQAN Priority: high Time line: with the new authZ service Reason: new authZ service is sufficiently close such that another effort is not justified MWSG Zurich, 30.3.2009

Cmds (4/4) task_removal: Given a credential find currently running jobs (and optionally remove them) Priority: high Blah will keep track of submitted jobs Allows to parse blah log file check_connection: new - courtesy of J.Keijser A script which verifies the openssl handshake to a service and returns success or failure with a meaningful reason J.Keijer volunteered MWSG Zurich, 30.3.2009

AuthZ Service Appendix Benefits of the service Feature list of the service MWSG Zurich, 30.3.2009

Feature List Policy examples Architectural features Implementation features Deployment features Operational features (for a site admin) Note: Prio1 = within EGEE-III Prio2 = beyond EGEE-III Label: +, -, o for advantage, skeptic, neutral Some of it are features by design, others are features that we are aiming at MWSG Zurich, 30.3.2009

Policy Examples: Banning (1/4) Banning users for a site (prio 1) + easy banning of users for a CE site administrator + banning groups of users, entire VOs, CAs, …. o single banning point for a site (site-wide banning) + possible - needs integration into DM Grid-wide banning (prio 1) + OSCT maintains a grid-wide ban list o sites must trust external policy VO-banning of users (prio 2) + VOs can ban the user without deregistering him Regional banning (prio 2) + regions/federations/nations can enforce banning rules MWSG Zurich, 30.3.2009

Policy Examples: VO policies (2/4) VO policies (prio2) - sites may oppose remote policies that they don’t understand + VO have a consistent means to communicate their policies to sites authZ users to run certain applications (prio2) + VOMS groups/roles are very limiting and don’t consider different types of applications (only admin role) + who is allowed to submit pilot/payload jobs + easy integration into VO specific services (prio2) o VO schedulers? o Decoupling FQAN-shares (prio2) Less important now (pilot jobs) Deferred topic - how relevant is it really today? MWSG Zurich, 30.3.2009

Policy Examples: DM (3/4) + use case of banning - implementation TBD - performance TBD - different SE implementations (DPM, dCache, CASTOR,…) o quota Open issue MWSG Zurich, 30.3.2009

Policy Examples: Other (4/4) + Better sharing of resources (prio2) E.g.access based on time + Better separation of responsibilities across Grid stakeholders (prio2) + combining different policies from the different stakeholders + adding new policies in a scalable way + Support for complex sites Ex: CERN site policy vs site specific VO policy vs running 20+ CEs MWSG Zurich, 30.3.2009

Architectural Features + Exposes policy of a site to the outside + Pre-requisite for a consistent authorization infrastructure across services + other services/users don’t have to second guess whether the job will be accepted + site has possibility for private policies + option of publishing policy or remote PDP invocation + High availability + extremely robust + every service component has HA + no single point of failure + no shared file system needed MWSG Zurich, 30.3.2009

Implementation Features + Thin PEP client + no dependencies on WN ! + adding other language bindings is easy + easy to integrate into other services + Standard compliant + use of a powerful authZ language (XACML) (+extendable) + SAML2-XACML2 profile + support for SAML assertions built-in from the beginning + credentials beyond PKI, VOMS SAML asssertions o Complexities of XACML hidden + CLI tools + Good performance o hard to get real requirements + aim for several hundred invocations per second + Several institutions are involved + long-term support MWSG Zurich, 30.3.2009

Deployment Features + Flexible deployment models Service can be deployed in various modes Default deployment model assumes installation of all components on one single host (supported by YAIM) + Gradual introduction into production infrastructure + no big bang + more services can use authZ service depending on their development cycle + no requirement that all sites make switch to use authZ simultaneously MWSG Zurich, 30.3.2009

Operational Features (for site admin) + easy to use (command line interface) + consistent logging, support for incident handling As defined in security command line tools + easy and simple monitoring interface Easy to find out whether all service components work and what it does (Nagios plug-ins will be delivered as part of the service) Command line interface + easy to troubleshoot + nagios plug-ins provided for service monitoring MWSG Zurich, 30.3.2009

EES + Consistent handling authZ - scheduling within a CE + Consistent way to add new execution environments + Support for new execution environments Virtual machines Workspaces Is a BIG job Hasn’t really been started yet MWSG Zurich, 30.3.2009

3rd Party Code Used OpenSAML / OpenWS: Jetty: Source: Shibboleth development team User base: Shibboleth project (~20-30mio users), Danish e-gov, OpenLiberty, ClaritySecurity (National Ass. Of Realtors) Jetty: Source: Mortbay User base: one of the three major open source servlet containers JBossCache: (in-memory replication) Source: JBoss / Red Hat User base: JBoss, Shibboleth 1.3 MWSG Zurich, 30.3.2009