1 / 5

Plugable Authorisation LCAS and beyond?

This document discusses the latest developments in the LCAS (Lightweight Community Authorization Service) framework for grid computing. It outlines version 1.3 enhancements, including pluggable authorization modules and the implementation of TLS authentication across various grid services. The focus is on achieving job-dependent, fine-grained authorization and integrating user credential information for improved job request handling. Additionally, it proposes modifications to gatekeeper services and the need for standardization of APIs for better grid resource management while addressing the challenges of existing GSI-based authorization methods.

tiara
Télécharger la présentation

Plugable Authorisation LCAS and beyond?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Plugable AuthorisationLCAS and beyond? WP4 – David Groep hep-proj-grid-fabric@cern.ch

  2. In release 1.3 Gatekeeper LCAS config TLS auth ACL Id timeslot Yes/no LCAS client gridmap LCMAPS clnt apply creds * Jobmanager-* WP4 LCAS Authorization Service • LCAS plugable authorization • User Credentials • Name • Full proxy • Job request details • Framework • combination of individual modules • Simple policy scheme (ordered) • Extensible (modules are .so ’s) • Near future (03Q1): ‘daemon’

  3. LCAS – modifications to service-level driver • Design goal for LCAS: job-dependent “fine-grained” authorization • Modules should avail over • User credential info • Job information • This context info exceeds what’s available on the GSI level: int lcas_get_fabric_authorization( gss_cred_id_t delegated_cred_handle, char *lcas_request); • therefore, modification to service (gatekeeper) are required • same hold for similar extension to GridFTP server (still needs API standardisation)

  4. Authorization Call-outs – GSI-only direction • Von’s proposal of September 13th: • Modify globus_gss_assist_gridmapfile • Support site-defined authorization + uid mapping call-outs • No fine-grained (no job-dependent authorization) • Requires mod’s to gridmap.c only (like the PoolAccounts) • Solves part of the authorization problem • Keeps authorization and credential mapping linked together • Jobs have to continue till site RMS to get rejected on budget, etc. • Is easy to do and has high potential for rapid acceptance (in PPDG+) • If we want fine-grained authZ, we should continue in the new GGF AuthZ working group!

  5. Per user policies and prios in the CE • Current schedulers (e.g. maui) do job management based on • Credentials (Unix uid+gid) and Accounts • Queue waiting time • Past usage and fair-share • Job attributed (requested time, memory, etc) e.g. for backfilling • Resources already used / in use • “queues” are no longer used! • You can influence scheduling locally by setting weights already now • Can lead to unexpected quirks! • Global scheduling based on free CPUs and Est. Traversal Time (ETT) • Currently: single estimate per “queue”, no policy info

More Related