FermiGrid - PRIMA, VOMS, GUMS & SAZ Keith Chadwick Fermilab

23 Oct 2006Keith Chadwick2 FermiGrid - Infrastructure Components Site Globus Gateway: Job forwarding gateway using CEMon. Makes use of “accept limited” globus gatekeeper option. VOMS & VOMRS: VO Membership Service & VO Management Registration Service. Allows user to select roles (FQANs). GUMS: Grid User Mapping Service. maps FQAN in x509 proxy to site specific UID/GID. SAZ: Site AuthoriZation Service. Allows site to to make fine grained job authorization decisions. MyProxy: Service to security store and retrieve signed x509 proxies.

23 Oct 2006Keith Chadwick3 FermiGrid - Current Architecture CMS WC1 CDF OSG1 CDF OSG2 D0 CAB2 SDSS TAM GP Farm LQCD Site Wide Gateway VOMS Server SAZ Server GUMS Server Step 1 - user issues voms-proxy-init user receives voms signed credentials Step 2 – user submits their grid job via globus-job-run, globus-job-submit, or condor-g Step 3 – Gateway requests GUMS Mapping based on VO & Role Step 4 – Gateway checks against Site Authorization Service clusters send ClassAds via CEMon to the site wide gateway BlueArc Periodic Synchronization Step 5 - Grid job is forwarded to target cluster

23 Oct 2006Keith Chadwick4 Globus gatekeeper - GUMS & SAZ interface GUMS and SAZ are interfaced to the globus gatekeeper through the gsi_authz callout: /etc/grid-security/gsi_authz.conf ##### PRIMA globus_mapping /usr/local/vdt/prima/lib/libprima_authz_module_gcc32dbg globus_gridmap_callout ##### SAZ globus_authorization /usr/local/vdt/saz/client/lib/libSAZ-gt3.2_gcc32dbg globus_saz_access_control_callout

23 Oct 2006Keith Chadwick5 SAZ - Site AuthoriZation Service We deployed the Fermilab Site AuthoriZation (SAZ) service on the Fermilab Site Globus Gatekeeper (fermigrid1) on Monday October 2, SAZ allows us (Fermilab) to make Grid job authorization decisions for the Fermilab site based using the DN, VO, Role and CA information contained in the proxy certificate provided by the user. We have currently configured SAZ to operate in a default accept mode for user grid proxy credentials that are associated with VOs (the user uses voms-proxy-init to generate their grid proxy credentials). Users that continue to use grid-proxy-init to generate their grid proxy credentials may no longer be able execute on Fermilab “SAZ enabled” Compute Elements.

23 Oct 2006Keith Chadwick6 SAZ Database Table Structure DN: user_name, enabled, trusted, changedAt VO: vo_name, enabled, trusted, changedAt Role: role_name, enabled, trusted, changedAt CA: ca_name, enabled, trusted, changedAt

23 Oct 2006Keith Chadwick7 SAZ - Site AuthoriZation Pseudo-Code Site authorization callout on globus gateway sends SAZ authorization request (example): user:/DC=org/DC=doegrids/OU=People/CN=Keith Chadwick VO:fermilab Role:/fermilab/Role=NULL/Capability=NULL CA:/DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1 SAZ server on fermigrid4 receives SAZ authorization request, and: 1.Verifies certificate and trust chain. 2. If [ the certificate does not verify or the trust chain is invalid ]; then SAZ returns "Not-Authorized" fi 3.Issues select on "user:" against the SAZDB user table 4. if [ the select on "user:" fails ]; then a record corresponding to the "user:" is inserted into the SAZDB user table with (user.enabled = Y, user.trusted=F) fi 5.Issues select on "VO:" against the local SAZDB vo table 6.if [ the select on "VO:" fails ]; then a record corresponding to the "VO:" is inserted into the SAZDB vo table with (vo.enabled = Y, vo.trusted=F) fi 7.Issues select on ”Role:" against the local SAZDB role table 8.if [ the select on “Role:" fails ]; then a record corresponding to the "VO-Role:" is inserted into the SAZDB role table with (role.enabled = Y, role.trusted=F) fi 9.Issues select "CA:" against the local SAZDB ca table 10.if [ the select on "CA:" fails ]; then a record corresponding to the "CA:" is inserted into the SAZDB ca table with (ca.enabled = Y, ca.trusted=F) fi 11.The SAZ server then returns the logical and of (user.enabled, vo.enabled, vo-role.enabled, ca.enabled ) to the SAZ client (which was called by either the globus gatekeeper or glexec).

23 Oct 2006Keith Chadwick8 SAZ - Animation Gatekeeper DN VO Role CA SAZ ADMINADMIN Job

23 Oct 2006Keith Chadwick9 SAZ - A Couple of Caveats What about grid-proxy-init or voms-proxy-init without a VO? The “NULL” VO is specifically disabled (vo.enabled=“F”, vo.trusted=“F”). If a user has user.trusted=“Y” in their user record then >>> we allow them to execute jobs without VO “sponsorship” <<<. This granting of user.trusted=“Y” is not automatic. The number of users with this privilege should be (will be) VERY limited. What about pilot jobs / glide-in operation? We have at least three options: We can just allow all DNs and Roles to be potential pilots. We can “anoint” the specific role used by the DN of the pilot glexec would call SAZ with the DN and role of the pilot first Then subsequently process the users DN and role. We can use two SAZ instances: The first is used by the gatekeeper and only has the pilot DN enabled. The second is used by glexec calls from the worker nodes and has all DNs enabled. More thinking may give us more options to choose from…

23 Oct 2006Keith Chadwick10 SAZ - Open Issues Extra /CN= in DN. Examples: /DC=org/DC=doegrids/OU=People/CN=Leigh Grundhoefer (GridCat) /CN= /DC=org/DC=doegrids/OU=People/CN=Leigh Grundhoefer (GridCat) /CN= /DC=org/DC=doegrids/OU=People/CN=Leigh Grundhoefer (GridCat) /CN= Result of user issuing grid-proxy-init. Does not occur in voms-proxy-init. Looking at code changes to handle “extra CN problem”. Condor fails to properly delegate the full voms proxy attributes. This can be worked around in condor_config by setting: DELEGATE_JOB_GSI_CREDENTIALS=FALSE A ticket on this issue has been opened with the Condor developers. Testing by Chris Green and John Weigand show that Reliable File Transfer (RFT) with WS-Gram is also failing to properly delegate the full voms attributes: RFT is using the full voms proxy for the first transaction, but uses a cached copy without the role information for the second transaction. A ticket on this issue has been opened with the Globus developers. We are also looking at what can be done inside SAZ.

23 Oct 2006Keith Chadwick11 SAZ - Extensions We are about to deploy a new SAZ client which can call multiple SAZ servers: Site wide SAZ instance Optional cluster specific SAZ instance. Job must pass all SAZ servers to be allowed to execute. We also are about to deploy a new SAZ server which ignores the extra /CN= which is added to the DN by grid-proxy-init. We are discussing the needs and options for a richer SAZ decision matrix and how to apply SAZ to storage access. We thinking about updates to the SAZ server in order to allow external configuration for default accept or default deny on each of DN, VO, Role and CA.

23 Oct 2006Keith Chadwick12 SAZ - Hourly Service Monitor

23 Oct 2006Keith Chadwick13 SAZ - Daily Metrics

23 Oct 2006Keith Chadwick14 SAZ - IP Connections per Day

23 Oct 2006Keith Chadwick15 SAZ - Unique DN, VO, Role, CA per Day

23 Oct 2006Keith Chadwick16 fin Any questions?