1. gLite Security Overview
Christoph Witzig, SWITCH
MWSG - March 30, 2009

2. 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,

3. EGEE Security Organization
JRA1 / Security Middleware Security Group
Grid Security Vulnerability Group Joint Security Policy Group EUGridPMA Operational Security Coordination Team
Security in EGEE-III: 440 PM
MWSG Zurich,

4. Security Layout
MWSG Zurich,

5. 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,

6. CE (1/2)
MWSG Zurich,

7. CE (2/2)
MWSG Zurich,

8. 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,

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

10. 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,

11. 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,

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

13. 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:
MWSG Zurich,

14. 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,

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

16. 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,

17. 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,

18. 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,

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

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

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

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

23. 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,

24. 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,

25. 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,

26. 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,

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

28. 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,

29. On the CE
MWSG Zurich,

30. 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,

31. 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,

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

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

34. 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,

35. 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,

36. 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,

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

38. Alternate Deployment Options (3/4)
MWSG Zurich,

39. Alternate Deployment Options (4/4)
MWSG Zurich,

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

41. 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,

42. 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,

43. Further Information About the service: General grid security: Other:
authZ service design document:
Deployment plan:
General grid security:
Authorization study:
gLite security: architecture:
Other:
Wiki: (just started, so pretty empty right now!)
EGEE08 presentations:
MWSG Zurich,

44. Summary
MWSG Zurich,

45. 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,

46. Backup Slides
MWSG Zurich,

47. Pattern Matching in gLite
C.Witzig, SWITCH
Security Architect EGEE

48. 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,

49. 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,

50. 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:
Future use:
To be uploaded (by tomorrow)
Exact transition date: TBA
MWSG Zurich,

51. Current Rules
MWSG Zurich,

52. 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,

53. /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,

54. New Rules
MWSG Zurich,

55. 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,

56. 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,

57. /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,

58. 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,

59. 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,

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

61. Security Command Line Tools
C.Witzig, SWITCH

62. 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
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,

63. 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,

64. 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,

65. 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,

66. 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,

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

68. 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,

69. 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,

70. 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,

71. 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,

72. 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,

73. 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,

74. 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,

75. 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,

76. 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,

77. 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,

78. 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,