National Institute of Advanced Industrial Science and Technology GGF12 Workshop on Operational Security for the Grid Cross-site authentication and access control panel Experiences in Asia Pacific Yoshio Tanaka Grid Technology Research Center, AIST, Japan

Architecture, technology Architecture, technology Based on GT2 Based on GT2 Allow multiple CAs Allow multiple CAs Build MDS Tree Build MDS Tree Grid middleware/tools from Asia Pacific Grid middleware/tools from Asia Pacific Ninf-G (GridRPC programming) Ninf-G (GridRPC programming) Nimrod-G (parametric modeling system Nimrod-G (parametric modeling system) SCMSWeb (resource monitoring) Grid Data Farm (Grid File System), etc. Status Status 22 organizations (10 countries) 23 clusters (1688 CPUs) Grids in Asia Pacific

Grass-roots Approach (strategy) Assumption Each institution has installed GT2 Necessary steps Gather and exchange trusted CA info. and trust with each other Configure MDS to build an ApGrid MDS tree For application use Install additional software in project-basis CA globus CA CA CA CA CA CA CA CA ApGrid GIIS

Status and problems Most participating organizations have less interests in Security Many participants are application people Not enough human resources working on security Satisfy in using Globus Simple CA without providing CP/CPS This would be acceptable inside AP for experimental use. potential/ongoing collaboration with US and EU e.g.: AIST/Japan – TeraGrid KISTI/Korea – PPDG and iVDGL ASCC/Taiwan – LCG … Need to launch production level CAs

APGrid PMA: Asia Pacific Grid PMA General Policy Management Authority in Asia Pacific Launched on June 1 st, 2004 Defines minimum CA requirements APGrid PMA approved that we accept two levels of CA: Experimental-level CA Alternative of the Globus CA Can be trusted within A-P communities Production-level CA Strict management is necessary Expected to be trusted by international communities KISTI GRID CA has been approved as a production level CA AIST GRID CA and ASGC CA are under reviewing their CP/CPS (expected to be approved shortly) Will discuss on interoperability issues between AP, EU and the US

Virtual Organization user 1 ( VO Manager ) service_c service_a Services and Users are exposed in a Virtual Organization Organization A service_c service_b service_a user 2 user 3 user 1 Contract A service_x service_y user p service_z service_x service_y user p user q user r Organization B Contract B PKI Domain VO Domain Identification and Authentication of VO membership Work in Japanese NAREGI (National Research Grid Initiative) Project ISSUES ： How to identify and authenticate members inside VO Design PKI architecture, trust relationship between end entity and CA Implementation issue of Globus and Unicore A virtual organization(VO) is a dynamic collection of resources and users unified by a common goal and potentially spanning multiple administrative domains. slide by courtesy of Ayako Komatsu (NEC)

ID & AUTH of VO membership (cont ’ d) Launch VO-CA that issues Public Key Certificates for end entities EE has both home PKC and a PKC issued by Compatible with Globus and Unicore Need to consider relationship between VO-CA and home CA Several implementation choices parent CA, child CA, bridged-CA, etc. Use attributes Manage membership information as an attribute of EE Authentication using a PKC issued by a home CA, then refer membership information Need to consider the scope of attributes slide by courtesy of Ayako Komatsu (NEC)

Identifier Access Rights Attribute Authenti cation Identity Federation Accoun ting Author ization Grid Computing NAREGI VO management architecture PKI GroupMgmt. Group VO Management Monit oring Human JobResource User Proxy UNICORE Globus Identifier slide by courtesy of Ayako Komatsu (NEC)

More Information ApGrid APGrid PMA My address