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

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
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
Application Logic by Web Pages
VEGA GOS v2
Architecture (hierarchical)
Grid Apps
Grid
Portal
Build-in Utility Collection
User Customized
Applications
Extended Utilities
Servlet Based Scalable Grid Portal Engine
User APIs
System and Application Libraries(Core Based Functional APIs and Exception Handling)
App Level
Services
Batch Service
System
Level
Services
GIS Service
Information(MetaX) Services
MetaFile Service
MetaDB
Meta Info
Service
Naming
Replica
Mgmt.
Mgmt.
Quota
Mgmt.
MetaSys
Service
File AC Mgmt.
Core APIs
Core
Level
Services
etc.
Workflow Service
Base Services
System
Monitoring
Service
Logging&
Auditing
Service
CA&
Certificates
Mgmt. Service
File
Database
Messaging
Service
Service
Service
Dymaic Deploy Service
Extended
System
Services
Core Libraries(Grip, Agora, Service Bus, AC Handling, Core Exception Handling)
Agora Service
User Mgmt. Engine
Resource Mgmt. Engine Agora
Profile
Service Addr. Service Mgmt.
Acct.
and PortType
Info
Proxy
Agora
Authentication
Cert.
Mapping
Mgmt.
AA
Role Based
Acct.
Multi-Grained
Acct. Mgmt.
Approve
Resource AC Policy Mgmt.
Authorization Engine
Router Service
GOS
Hosting
Env.
etc.
Tomcat
(Apache)
Service Info. Mgmt. (Local)
OMII
GT4
(Globus)
WebSphere
(IBM)
Grip Service
Grip Container
Result
Caching
User
Interaction
Grip State Mgmt.
Grip Ctrl. Structure
Addr. Core Exceptions
Trans. Service Invocation
Service Locating(Global)
WebLogic
(BEA)
Java J2SE, J2EE/Microsoft Windows
.NET
(Microsoft)
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>
and “write” that parsed by service side
<Action Namespace="0">ping</Action>
</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
•return
•cache
Physical Service
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
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



Agora (VO, Community) Based Authorization


Loosely coupled
Multi-grained access control implementation
mechanism according to info carried by token


Header and attachment, Which one is the best place for
security info? (my opinion)
Implementations are different, how can be interoperable?
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!