LCASLCMAPS 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

3
Authorization context
Policy comes from many stakeholders
Graphics from Globus Alliance GGF OGSA-WG
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)

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)

6
Whats 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

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

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)

9
LCMAPS control flow
LCMAPS
GK

• 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
10
LCMAPS modules

• Modules (representing atomic functionality)
• Acquisition
• VOMS extract VOMS credentials from the proxy
• PoolAccounts from username assign unique uid
• PoolGroups from (VOMS) groupname assign unique
  gid
• LocalAccount from username assign local existing
  uid
• LocalGroups from (VOMS) groupname assign
  existing gid
• VOMS PoolAccounts from usernameprimary
  VOMS assign unique uid
• AFS/Krb5 get token based on user DN info via
  gssklogd
• Enforcement
• POSIX process setuid() and setgid()
• POSIX LDAP update distributed user database

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

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/

13
LCMAPS WSS via legacy mode
14
LCMAPS usage in the job chain
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?