The VEGA Approach to Grid Security

1. The VEGA Approach to Grid Security --Security In VEGA GOS v2 Grid System Software Group, ICT, CAS 2005-4-11 Li ZHA char@ict.ac.cn

2. 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

3. 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

4. Application Scope of VEGA GOS Manufacturing Resources and Environment Weather Forecast ScienceResearch VEGA GOS Distributed Resources and Services

5. 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?

6. 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

7. VEGA GOS v2 Architecture (hierarchical)

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

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

10. 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

11. E2E Message Process Flow

12. Client Request/Service Response SOAP Header <!-- SOAP begin…(SOAP Element)--> <soapenv: Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Soapenv: Header> <! -- Certs Type --> <CertType soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next" soapenv: mustUnderstand="0"> <Type>cert</type> </CertType> <!-- Security Element. --> <wsse: Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext" soapenv: actor="" soapenv: mustUnderstand="0"> <!--Encoding Binary Security Tokens. --> <!-- This element is used to include a binary-encoded security token. --> <wsse: BinarySecurityToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/04/utility" EncodingType="wsse: Base64Binary" ValueType="wsse: PKIPath" wsu: Id="token1112843580450">.........</wsse: BinarySecurityToken> <!-- WS-Security Signature --> <ds: Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <!-- SignatureValue --> <ds: SignatureValue>.........</ds: SignatureValue> <!-- KeyInfo, indicates the key to be used to validate the signature. --> </ds: Signature> </wsse: Security> </soapenv: Header>

13. 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

14. Agora Internals Tomcat+Axis Agora Access Control Mechanism User Authentication Resource Authorization AC Policy Mgmt. Resource Mgmt. Interface User Mgmt. Interface Agora Mgmt. Authorization Engine Resource Mgmt. Client User Mgmt. Client AAA Client Tomcat+Axis Tomcat+Axis Tomcat+Axis Resource Mgmt. Service User Mgmt. Service Authorization Authority Service VRes ERes Mapping PT User Name Role Proxy profile

15. SAML based authorization token ... <Conditions NotBefore=" " NotOnOrAfter=" "> <AudienceRestrictionCondition> <!-- extended authorization info, such as info added by metaX service --> <Audience>FILE PATH to local storage</Audience> </AudienceRestrictionCondition> </Conditions> <!-- reference infomation help service side implementing access control --> <Advice> ...... </Advice> <AuthorizationDecisionStatement Decision="Permit" Resource="vres://ed3ee2ed0d9ba0085db0fe8df40e8bd9:4b284f96f21f8fde00ba45218c9e8eea"> <Subject> <NameIdentifier> O=Grid,OU=GOSTEST,OU=grid.org.cn,OU=linux.ict.ac.cn,CN=usr1 </NameIdentifier> </Subject> <Action Namespace="0">ping</Action> </AuthorizationDecisionStatement> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ... <!-- signature related info algorithm, digest and signature valueetc.--> ... </ds:Signature> ... user DN can be logical operations, such as “read” and “write” that parsed by service side access control mechanism

16. 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

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

18. 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); ... parameters passed to actual service synchronization flag

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

20. VEGA GOS v2 Deployment

21. 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

22. VEGA GOS v2 Roadmap • Time Schedule • 2005.3, GOS v2 Alpha (prototype) • 2005.4, GOS v2 Beta (barely fixed) • 2005.5, GOS v2 release (include sample application and full documents)

23. CNGrid： http://www.grid.org.cn/ Thanks! VEGA： http://vega.ict.ac.cn/ GOS mailing list： gos@software.ict.ac.cn