Home Up Feedback Contents Search

 
Security Challenges

 

 

 

Architecture

 

 

Sponsor Links

IBM Virtualization Engine Grid Toolbox for Multiplatforms - ( v. 1.x ) - media
HP/Compaq Proliant BL20p G3 Blade Server
IBM eserver BladeCenter HS20 8832 - Xeon 3.2 GHz
logo_88x31
HP StorageWorks Modular SAN Array 1000, includes one controller and one single-port Fibre Channel I/O Module
Hotwire.com
Intel Server Compute Blade SBXL52 - no CPU
Red Hat Linux Advanced Server
Intel Cluster Math Kernel Library for Linux - ( v. 7.x ) - complete package
Dell Outlet
Intel Blade Server Chassis SBCE - desktop - 7 U
iBook G4
HP Installer Kit for Linux - media
HP StorageWorks Continuous Access EVA - ( v. 1 ) - complete package
HP Fabric Manager Enterprise - ( v. 4.x ) - complete package
IBM Cluster Systems Management Base for Xlinux/EServer - ( v. 1.4 ) - media
HP F500 Cluster for EVA Basic
S/W Integration Kit for HP OpenView NNM SNMP MGMT
HP StorageWorks 300mx MO Jukebox 2 Drives , 291.2 GB
Novanet Microsoft Clusters
HP StorageWorks Magneto-Optical Storage 2200mx , 2.17TB
FreeShip_468X60

Security for Virtual Organizations: Federating Trust and Policy Domains

SECTION 1
Requirements
Grid Society
Example
Challenges
Architecture
Trust Domains
Dynamic Services

SECTION 2
Coming soon


SECTION 3

Coming soon

 

<< 1 2 4 5 6 >>

 

Excerpt from chapter 21 of Grid 2: Blueprint for a New Computing Infrastructure.


21.1.3 Security Challenges and Requirements

Security requirements within the Grid environment are driven by the need to support scalable, dynamic, distributed virtual organizations (281) (VOs, Chapter 4)— collections of diverse and distributed individuals and organizations that seek to share and use diverse resources in a coordinated fashion. The VO concept serves as the basis for the Grid security model that we introduce to support scenarios such as that in Section 21.1.2: Resources from multiple locations are coordinated to serve an even larger, more distributed collection of users.

From a security perspective, a key attribute of VOs is that, in addition to VO-specific policy, participants and resources are governed by the rules and policies of the classical organizations of which they are members. Furthermore, whereas some VOs, such as the multiyear scientific collaboration given in the example, will be large and long-lived (in which case explicit negotiations with resource providers are acceptable), others will be short-lived—created, perhaps, to support a single task, such as two individuals sharing documents and data as they write a proposal—in which case overheads associated with VO creation and operation must be minimal.

A fundamental requirement is thus to enable access by VO members to resources that live within classical organizations and that, from the perspective of those classical organizations, have policies in place that speak only about local users. This VO access must be established and coordinated only through binary trust relationships that exist between the local user and their organization and between the VO and the user. We cannot, in general, assume trust relationships between the classical organization and the VO or its external members.

Grid security mechanisms can address these challenges by allowing a VO to be treated as a policy domain overlay (see Figure 21.2). Multiple resources or organizations outsource certain policy control(s) to a third party, the VO, which coordinates the outsourced policy in a consistent manner to allow for coordinated resource sharing and use.


 

Figure 21.2: A virtual organization policy domain overlay pulls together participants and resources from disparate domains into a common trust domain.

Complicating Grid security is the fact that new services (i.e., resources) may be deployed and instantiated dynamically over a VO’s lifetime. For example, a user may establish personal stateful interfaces to existing resources, or the VO itself may create directory services to keep track of VO participants. Like their static counterparts, these resources must be securely coordinated and must interact with other services.

This combination of dynamic policy overlays and dynamically created entities drives the need for three key characteristics in a Grid security model:

  • Enables integration and interoperability. Organizations participating in a VO often have significant investment in existing security mechanisms and infrastructure. Grid security, rather than replacing these mechanisms, must enable integration and interoperability between them.

  • Enables creation and management of dynamic trust domains. Not only must parties in a VO be able to interoperate at the level of protocols, but in order to coordinate resources, VOs need to establish trust among VO users and resources. These trust domains can span multiple organizations and must adapt dynamically as participants join or leave the VO.

  • Supports dynamic creation of services. Users must be able to create new services (e.g., “resources”) dynamically without administrator intervention. These services need to be coordinated and must interact securely with other services.

Thus, we must be able to name the service with an assertable identity and grant access rights to that identity without contradicting the governing local policy.

Traditional means of security administration that involve manual editing of centralized policy databases or issuance of credentials through elaborate procedures cannot meet the demands of these dynamic scenarios. We require a user-driven security model that allows users to create entities and policy domains in order to create and coordinate resources within VOs.

<< 1 2 4 5 6 >>
 

Button_120x90_C
ipodphoto120x90
static foncentral_120x90
Build Upgrade Replace - Animated
 

 

 

Home ] Up ] Architecture ]

Send mail to with questions or comments about this web site.
Copyright © 2005-7 GridSummit.com
Last modified: 10/30/07