The VEGA Approach to Grid Security Grid System Software Group, ICT, CAS Security In VEGA GOS v2 Li ZHA

Outline Background of VEGA GOS Motivations And Goals Security In VEGA GOS  VEGA GOS Architecture  Grid Security Mechanism Key Approaches  WS-Security Implementation  Agora (VO, Community) Based Authorization  Runtime construct (Grip, Grid Process) for secured accessing the service Hosting Environment And Deployment Conclusion And Roadmap

Background of VEGA GOS Background  Grid related research and the VEGA brand at ICT since 1999  Part of the Grid Software program supported by the China Ministry of Science and Technology 863 program (2002~2005) Goals  Support multiple geographical distributed grid nodes (HPC Center)  Sharing mechanism and framework on computing, data, software and combined resources  Provide secured, uniformed and friendly interfaces accessing the scientific computing and information services Research  Focus on 4 key issues and aim at minimal common requirements Naming, Process/States, VO, Programming  Focus on implementation architecture, not protocols/services Use computer systems approach, not middleware or network Use SOA concept

Application Scope of VEGA GOS VEGA GOS Distributed Resources and Services Science Research ManufacturingResources and Environment Weather Forecast

Motivations And Goals -- What is needed In grid environment, security should solve or cover:  Traditional security issues such as authentication, access control, information integrity, information privacy (according to OSI security architecture)  Grid authentication Single Sign On  Grid authorization Adapt to loosely coupled or de-coupled architecture Access control decided by resource owner or provider  Communication security guarantees Adopt opened and standardized protecting mechanism (signature, encryption, and etc.)  All the information separated or put together? How to put them together?

Motivations And Goals -- More concrete Integrate security with Web service and VEGA GOS  Independent with service implementations (utilizing handler-chain mechanism at client and service sides) Conformed to existing security standards  X.509 (for authentication)  SAML (for authorization)  WS-Security Implementation (for service oriented security architecture)  Standard signature and encryption algorithms Ensure mutual security at both user and resource sides  User and Service MUST both have certificates Departs authorization with authentication  Token based authorization (tokens are dynamically issued by Authorization Authority in Agora)  GOS context (Agora id, cert/proxy cert and token) is added into each SOAP message when accessing the service Keep resource as autonomous  Implement access control at resource side with interfaces which can be customized  Multiple granularity access control based on authorization token

VEGA GOS v2 Architecture (hierarchical)

Security Mechanism In VEGA GOS v2 Browser uCert Grid Portal Engine use uid/pass load proxy cert into grip Grip Container Service Agora Service u_p Physical Service u_p uTK u_p uTK u_p uTK u_p uTK User Mgmt. Service Resource Mgmt. Service AA Service uTK Grid Application uCert user cert u_p proxy cert uTK authorization token Physical Service Physical Service Physical Service Grid Portal CA u_p upload the proxy cert to Agora u_p

Key Approaches WS-Security Implementation Agora (VO, Community) Based Authorization Runtime construct (Grip, Grid Process) for secured accessing the service

WS-Security Implementation Handler chains mechanism  Sign SOAP message, add cert (or proxy cert) and token  Authenticate caller’s and AAA’s identification  Implement access control GOS context  A common system object storing Agora id, cert or proxy cert (with key), token in a structured manner

E2E Message Process Flow

Client Request/ Service Response SOAP Header cert

Agora Based Authorization Separate authorization from authentication  Agora Authorization Authority can dynamically issue tokens according to trusted resource request  Flexible authentication at service side according to handler configurations Implement multiple grained resource access control  Token can contain service operations or logic operations  Service side ACHandler implement access control integrate with local security policy

Agora Internals Tomcat+Axis Agora Access Control Mechanism Authorization Engine Resource Mgmt. ClientUser Mgmt. Client User Authentication Resource Authorization Resource Mgmt. Interface User Mgmt. Interface Resource Mgmt. ServiceUser Mgmt. Service RoleProxy User Name profile ERes Mapping VResPT Tomcat+Axis AAA Client Authorization Authority Service AC Policy Mgmt. Agora Mgmt.

SAML based authorization token... FILE PATH to local storage O=Grid,OU=GOSTEST,OU=grid.org.cn,OU=linux.ict.ac.cn,CN=usr1 ping can be logical operations, such as “read” and “write” that parsed by service side access control mechanism user DN

Runtime construct (Grip, Grid Process) for secured accessing the service Dynamically created at runtime  responding to user requests  simple interfaces (5 in total) Keep some information for reusing  Load and store proxy cert, user profile and service address  Destroyed until grip closed Relay user’s invocation requests  Extends called service with an asynchronous interface  Cache the returned result, such as batch job query status

Physical Service Grip At Runtime create Agora Service grip uid/pass Proxy, Profile bind ERes name VRes name, Token, PT invoke Physical Service crtl (getResult) grip Network of Resource Routers authentication resource selection resource authorization resource locating service invocation return cache close uCert_p Profile uCert_p Profile VRes Token PT uCert_p Profile VRes Token PT PRes Ret uCert_p Profile VRes Token PT PRes

Sample Code Using Grip... //define effective resource name String effective = "eres://agora1:MService"; //new a gripclient object GripClient testgripclient = new GripClient( ); //create a grip with user id, passwd and //agora name want to login UserHandle griphandle = testgripclient.create("usr1", "usr1", "agora1"); //bind the effective resource int index = testgripclient.bind(effective, griphandle); //invoke the bound service by resource index and //pass the parameters required Object retvalue = testgripclient.invoke(index, "list", new Object[] {"/"}, GripContainer.M_SYNCHRONIZED, griphandle);... //process the return value here... //close it, reclaim the resources used by grip testgripclient.close(griphandle);... synchronization flag parameters passed to actual service

VEGA GOS v2 Hosting Environments Grid Portal and Grid Applications OS (Linux/Unix/Windows*) Intel or AMD based PC Server (Grid Server) J2SE( 1.4.2_07 ), J2EE Tomcat( ) +Axis( 1.2 rc2 ) Axis Handlers For Message Level Security Grid Portal Engine Core, System And App Level GOS v2 Services

VEGA GOS v2 Deployment

Conclusion WS-Security Implementation and integrated into VEGA GOS  Header and attachment, Which one is the best place for security info? (my opinion)  Implementations are different, how can be interoperable? Agora (VO, Community) Based Authorization  Loosely coupled Multi-grained access control implementation mechanism according to info carried by token  Adapt to resource provider side’s security mechanism Runtime construct (Grip, Grid Process) for secured accessing the service  Simple and easy to use

VEGA GOS v2 Roadmap Time Schedule  , GOS v2 Alpha (prototype)  , GOS v2 Beta (barely fixed)  , GOS v2 release (include sample application and full documents)

GOS mailing list ： CNGrid ： VEGA ： Thanks!