OSG/TeraGrid Interopations: The Authz Perspective Von Welch (NCSA) Presenting work by Christopher A. Baumbauer (Purdue U.) Greg Cross (U. Chicago) Stuart Martin (ANL/U. Chicago)

Background Initial effort to allow OSG users to acess TG resources –Primarily focused on job submission Background –OSG uses VOMS to enumerate users and assert their roles –TG currently is using grid-mapfile-based scheme No attributes currently No support for mapping VOMS groups/roles to account in TG software stack (CTSS)

OSG/TG Information Exchange TG and OSG experts hooked up TG and OSG accept each others CAs TG can find out OSG users and roles by pulling information from OSG VOMS servers using edg-mkgridmap TG can then put this information (or some subset) into its grid-mapfiles

Account Management Lingering issue is one of account management - what local account does TG use for OSG users? Expectation is to use OSG community account(s) via gridmapfile –I.e. statically map OSG users to OSG local account –Assumption is small percentage of OSG users will use TG, so created accounts for all is wasteful and non-scalable Initially one account, probably move to handful of accounts for handful of OSG roles –Will not be acceptable to all TG sites, expect only some will participate

Decomposing the Process Although authz infrastructures are different it can work First, manual bootstrap exchange of high- level relatively static policy information –What person/group speaks for the VO policy? –Trust roots CAs VOMS servers Etc –List of groups and roles and what those groups and role convey (the semantics) –Software stack, etc.

Decomposing (cont) After initial bootstrap, an automated and regular information exchange process follows –Changes to trust roots Additions, revocations, etc. –Software changes –User list –User attributes - groups and roles