The VEGA Approach
to Grid Security
--Security In VEGA GOS v2
Li ZHA
char@ict.ac.cn
Grid System Software Group,
ICT, CAS
2005-4-11
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
„
Goals
„
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)
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
Manufacturing
Resources and Environment
Weather
Forecast
Science
Research
VEGA GOS
Distributed Resources and Services
Motivations And Goals -- What is needed
„
In grid environment, security should solve or cover:
Traditional security issues
„
Grid authentication
„
„
Adapt to loosely coupled or de-coupled architecture
Access control decided by resource owner or provider
Communication security guarantees
„
Single Sign On
Grid authorization
„
such as authentication, access control, information integrity,
information privacy (according to OSI security architecture)
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
uCert
Browser
use uid/pass load
proxy cert into grip
u_p
upload the proxy
cert to Agora
Grid Portal
uCert
CA
Grid Application uCert
Grid Portal Engine
user cert
uTK
Agora
Service
u_p
u_p
u_p
u_p
u_p
proxy
cert
uTK
authorization
token
Grip Container Service
u_p
uTK
Physical
Service
u_p
uTK
Physical
Service
User
Mgmt.
Service
u_p
uTK
Resource
Mgmt.
Service
AA
Service
u_p
uTK
Physical
Service
Physical
Service
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 Side
SignHandler(with proxy
or user cert)
AddGOSContextHandler
WS
Client
request flow
SOAP MSG over
SSL/TSL(HTTPS)
WSSecurityHandler
GetAttachmentsHandler
VerifyCertsHandler
VerifyTokenHandler
response flow
WSSecurityHandler
GetAttachmentsHandler
VerifyCertsHandler
VerifyTokenHandler
ACHandler
SignHandler (with
service cert)
AddGOSContextHandler
Server Side
Web
Service
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>
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
User
Resource
Authentication Authorization
AC Policy
Mgmt.
Resource
Mgmt.
Interface
User
Mgmt.
Interface
Agora
Mgmt.
Authorization Engine
Resource Mgmt. Client
Tomcat+Axis
Resource Mgmt. Service
VRes ERes
Mapping
PT
User Mgmt. Client
Tomcat+Axis
User Mgmt. Service
User
Role Proxy profile
Name
AAA Client
Tomcat+Axis
Authorization
Authority
Service
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:4b284f96f21f8fde00ba45
218c9e8eea">
user DN
<Subject>
<NameIdentifier>
O=Grid,OU=GOSTEST,OU=grid.org.cn,OU=linux.ict.ac.cn,CN=usr1
</NameIdentifier>
can be logical operations, such as “read”
</Subject>
<Action Namespace="0">ping</Action>
and “write” that parsed by service side
</AuthorizationDecisionStatement>
access control mechanism
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
<!-- signature related info algorithm, digest and signature value etc. -->
...
</ds:Signature>
...
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
Grip At Runtime
create
bind
grip
•uCert_p
Profile
invoke
crtl
(getResult)
close
grip
authentication
uid/pass
Proxy, Profile
ERes name
VRes name, Token, PT
•resource
selection
Agora
•resource
Service
authorization
•uCert_p
•uCert_p
•uCert_pProfile grip Profile
Profile VRes
VRes
VRes Token
Token
grip Token PT
PT
PT
PRes
PRes
resource
Ret
locating
•return
•cache
Physical Service
service
Network of Resource Routers invocation
Physical Service
Physical Service
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",
"agora1");
"usr1",
//bind the effective resource
int index = testgripclient.bind(effective, griphandle);
//invoke the bound service by resource index and
//pass the parameters required
parameters passed to
actual service
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
VEGA GOS v2 Hosting Environments
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
Deployment
Legacy
Applications
HPC Hosting Env.
To Other
Grid Nodes
To Other
Grid Nodes
Grid Node 3
(Xi’an)
Legacy
Applications
Grid Server
HPC Hosting Env.
Grid Node 2
(Shanghai)
Legacy
Applications
Grid Server
Router service
Agora service
Grip service
System and application level
services
Grid portal based on Grid
Portal Engine (optional)
Grid
Server
HPC Hosting Env.
Grid Server
Grid Node 4
(Changsha)
Grid CA
Grid Server
Legacy
Applications
HPC Hosting Env.
Grid Node 1
(Beijing)
Grid Client
General Web Browser
and/or GOS Admin Tools
and/or GOS API Based Grid
Application
Web Browser
Dedicated Client/
Grid Application Client
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
„
Multi-grained access control implementation
mechanism according to info carried by token
„
Loosely coupled
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
2005.3,
GOS v2 Alpha (prototype)
2005.4, GOS v2 Beta (barely fixed)
2005.5, GOS v2 release (include sample
application and full documents)
CNGrid： http://www.grid.org.cn/
VEGA： http://vega.ict.ac.cn/
GOS mailing list： gos@software.ict.ac.cn
Thanks!