LCAS/LCMAPS and WSS Site Access Control boundary conditions

INFSO-RI-508833

Enabling Grids for E-sciencE

www.eu-egee.org

LCAS/LCMAPS and WSS Site Access Controlboundary conditions

David Groep

NIKHEF

Site Access Control LCAS/LCMAPS and Unix-domain limitations, September 12, 2005 2


INFSO-RI-508833

Outline

• Local authorization• LCAS: making authorization decisions• LCMAPS: integrating with UNIX accounts



INFSO-RI-508833

Authorization context

Key Material

Group of unique names Organizational role

Server

UserAttributesVO

Policy

ResourceAttributesSite

Policy

Policy

Authorization PolicyArchitecture

Local SiteKerberosIdentity

PolicyEnforcement

Point

VOOther

Stakeholders

Site/Resource

OwnerAuthorization

Service/PDP

Policy andattributes.

Allow orDeny

Resource

Standardize

Delegation

User

Process actingon user’s behalf

PKI/KerberosIdentity

TranslationService

PKIIdentity

Delegation Policy

Graphics fromGlobus Alliance& GGF OGSA-WG

Policy comes from many stakeholders



INFSO-RI-508833

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)



INFSO-RI-508833

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)



INFSO-RI-508833

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



INFSO-RI-508833

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



INFSO-RI-508833

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)



INFSO-RI-508833

LCMAPS – control flow

• 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

CREDs

LCMAPSCredential Acquisition

& Enforcement

Job Mngr

GK



INFSO-RI-508833

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 username+primary 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• …



INFSO-RI-508833

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.

# 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

example



INFSO-RI-508833

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/



INFSO-RI-508833

LCMAPS & WSS via legacy mode



INFSO-RI-508833

LCMAPS usage in the job chain



INFSO-RI-508833

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?

LCAS/LCMAPS and WSS Site Access Control boundary conditions

Documents

Transcript of LCAS/LCMAPS and WSS Site Access Control boundary conditions