LCAS/LCMAPS and WSS Site Access Control boundary conditions

1. LCAS/LCMAPS and WSS Site Access Controlboundary conditions David Groep NIKHEF

2. Outline • Local authorization • LCAS: making authorization decisions • LCMAPS: integrating with UNIX accounts Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

3. Authorization context Policy comes from many stakeholders Graphics from Globus Alliance& GGF OGSA-WG Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

4. Local Authorization • EGEE Architecture • Policy providers orchestrated by a master PDP (not shown) • Authorization Framework (Java) and LCAS (C/C++ world) • both provide set of PDPs (should be the same set, or a callout from one to the other) • PDPs foreseen: • user white/blacklist • VOMS-ACL • Proxy-lifetime constraints • Certificate/proxy policy OID checks • peer-system name validation(compare with subject or subjectAlternativeNames) Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

5. Local Authorization Today • Current Implementation • Only a limited set of PDPs: • ban/allow and VOMS-ACL • Authorization interface is non-standard (at least for C/C++) • All evaluation is in-line: • source modifications needed to old services (GT gatekeeper, GridFTP server) • recent versions of the framework for Java needed (i.e. GT4+) • No separate authorization service (no site-central checking) • Policy format is not XACML everywhere (i.e. GACL) Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

6. What’s within reach? • Standard white list, blacklist service for all services • Some additional PDPs • Policy OID checking • Proxy certificate lifetime constraints • Limit to specific executable programs • Better integration between Java and C worlds Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

7. LCMAPS Once authorisation has been obtained • acquire local (Unix) credentials to run legacy jobs • enforce those credentials on • the job being run or • FTP session started • LCMAPS is the back-end service used by • GT2-style edg-gatekeeper (LCG2) • edg-GridFTP (LCG2) • glexec/grid-sudo wrapper • WorkSpace Service Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

8. LCMAPS – requirements • Backward compatible with existing systems • should read a grid-mapfile • legacy API transparent replacement • pluggable into other systems (gatekeeper, gridFTP, …) • Support for multiple VOs per user • VOMS groups, roles and capabilities map into UNIX groups • granularity can be configured per site (from 1 group/VO to 1 per unique triplet) – but should it? • Mimimum system administration intervention • pool accounts, and pool ‘groups’ • understandable configuration • Extendible and configurable • Boundary conditions • has to run in privileged mode • has to run in process space of incoming connection (for fork jobs) Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

9. LCMAPS – control flow GK LCMAPS • User authenticates using (VOMS) proxy • LCMAPS library invoked • Acquire all relevant credentials • Enforce “external” credentials • Enforce credentials on current process tree at the end • Run job manager • Fork will be OK by default • Batch systems may need primary group explicitly • Batch clusters will need updated (distributed) UNIX account info • Order and function: policy-based Credential Acquisition & Enforcement CREDs Job Mngr Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

10. LCMAPS – modules Modules (representing atomic functionality) Acquisition • VOMS extract VOMS credentials from the proxy • PoolAccountsfrom username assign unique uid • PoolGroupsfrom (VOMS) groupname assign unique gid • LocalAccountfrom username assign local existing uid • LocalGroupsfrom (VOMS) groupname assign existing gid • VOMS PoolAccountsfrom username+primary VOMS assign unique uid • AFS/Krb5get token based on user DN info via gssklogd Enforcement • POSIX processsetuid() and setgid() • POSIX LDAPupdate distributed user database • … Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

11. example # groupmapfile "/VO=iteam/GROUP=/iteam*" iteam "/VO=WP6/GROUP=/WP6*" wpsix "/VO=wilma/GROUP=/wilma" wilma "/VO=wilma/GROUP=/wilma/*" .pool "/VO=fred/GROUP=/fred*" .pool LCMAPS – functionality view • Local UNIX groups based on VOMS group membership, roles, capabilities • More than one VO/group per grid user allowed [but…] • Primary group set to first VOMS group – accounting • New mechanisms could mitigate issues: • groups-on-demand, support granularity at any level • Central user directory support (nss_LDAP, pam-ldap) Not ready – and priorities have not been assigned to this yet. Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

12. Work Space Service On the road towards virtualized resources: Work Space Service • Managed accounts • enable life cycle management • controlled account management (VO can request/release) • “special” QoS requests • WS-RF style GT4 service • uses LCMAPS as a back-end http://www.mcs.anl.gov/workspace/ Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

13. LCMAPS & WSS via legacy mode Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

14. LCMAPS usage in the job chain Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005

15. Summary • Control over running jobs is via site mechanisms • Mapping of credentials required for legacy programs • limited to Unix domain account mechanisms • Needs to remain manageable for site administrators • Scheduling/priorities based on Unix user and group names • Accounting based on uid, gid pairs • Unix domain is not very flexible. Sorry. • Virtualisation is coming, but too far down the road? Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005