90 likes | 257 Views
EGEE Authorization H&N. David Groep et al. EGEE JRA3. Authorization. AuthZ Architecture Authorization framework for Java and C With policy providers orchestrated by a master PDP For today: Authorization Framework (Java) and Local Centre Authorization Service LCAS (C/C++ world)
E N D
EGEE Authorization H&N David Groep et al. EGEE JRA3
Authorization • AuthZ Architecture • Authorization framework for Java and C • With policy providers orchestrated by a master PDP For today: • Authorization Framework (Java) and Local Centre Authorization Service LCAS (C/C++ world) • both provide set of PDP implementations (should be the same set, or a callout from one to the other) • Fine-grained AuthZ implemented as part of service • e.g. for Data Management LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
Context cache PEPService ormessageinterceptor decision PDP PIP PIP PDP User inblacklist? RetrieveVO info Retrievelocal info evaluate Chain 1 ... OR Chain 2 ... = PAP accessible interface Authorization Framework • Implemented in Java only • Module interfaces subtly different from the GT4 ones, but no show-stopper LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
LCAS and Java PDPs My best status info as of last week, with bias towards the CE: * in a non-standard (gacl) format that will change 2007 + interface is partly proprietary, change planned RSN™ LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
Gatekeeper LCAS User accept VOMS Authentication Context+ JobInfo banlist LCAS authZ call out exectbl LCMAPS open, learn,&run: … and return legacy uid Job Manager fork+exec args or submit C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy VOMSpseudo-cert LCMAPS and Job Submission • LCMAPS : mapping attributes to the Unix domain • based on fine-grained VOMS roles/groups • must bepart of the job runtime chain • setuid(2) needs to actually enforce • source modifications needed to legacy services • Supported in Gatekeeper, GridFTP, glexec, DPM/LFC* LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
The new gLite CE • In the EGEE gLite CE Architecture LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
LCMAPS functionality • Unix mapping based on VOMS groups, roles • Granularity set by the site administrator • Several VOMS-level grp/roles can be mapped on a single GID • Supports pool groups as well as pool accounts • Primary Unix group set to first VOMS group • for accounting purposes • for use by schedulers in setting priority LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
LCMAPS deployment constraints • More than one VO/group per grid user allowed [but…] • Each VOMS unique FQAN listed can translate into 1 Unix group id • Each user-unix group combination translates into 1 Unix user id • When job starts on a worker node, identity is re-instated outside of LCMAPS control by the batch system: • For sites that do not support a modifiable central user database:need a set of poolaccounts for each site-local unix group • Unix domain is just not flexible enough. Sorry. • There are (of course) ideas to circumvent these issues • Central user directory support (nss_LDAP, pam-ldap) • Acceptance may stay far away • Data Management systems preferably use native, fine-grained system LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006
Fresh fruit? • Virtualisation is here now … • Xen, VMware Player/Server, … • Needs modification of job managers and batch system pre/postrun scripts • Great fresh low-hanging fruit? • WSS is part of the chain now • Batch system modifications are quite doable • Will help greatly in addressing the translation problem ‘how to defend yourselves against anyone who attacks youarmed with a piece of fresh fruit ‘ LCAS and LCMAPS and Unix-domain limitations, GGF16, February 2006