Security for Virtual Organizations: Federating Trust and Policy Domains

SECTION 2
Coming soon

SECTION 3
Coming soon
 

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

21.1.3.1 Implementation Agnostic and Interoperable Architecture

For both technical and pragmatic reasons, no single security technology that will both addresses all Grid security challenges and can be adopted in every hosting environment can be defined. Even if new standards are adopted, existing security infrastructures cannot be replaced overnight. For example, each domain in a Grid environment is likely to have one or more registries in which user accounts are maintained (e.g., LDAP directories); such registries are unlikely to be shared with other organizations or domains. Similarly, authentication mechanisms deployed in an existing environment reputed secure and reliable will continue to be used. Each domain typically has its own authorization infrastructure that is deployed, managed, and supported. It will not be acceptable to replace any of these technologies with a single model or mechanism.

Thus, to be successful, Grid security architecture must integrate with, rather than replace, security architectures, models, and implementations deployed in domains and hosting environments. This means that the architecture must be implementation agnostic, allowing it to be instantiated in terms of a variety of existing security mechanisms (e.g., Kerberos, public key infrastructure) and allowing it to incorporate new security services as they become available.

These traits enable the deployment of Grid security in a single domain but do not enable two different deployments to interact. Different domains and hosting environments make different decisions regarding the mechanisms and policies they use. Distributed applications that traverse services, servers, hosting environments, and security domains need to be able to interact with each other, thus introducing the need for interoperability.

Interoperability between conversing parties is achieved only if they can interoperate (at least minimally) at every layer involved in a message exchange:

• At the transport layer, an agreed-upon transport mechanism to send messages is required. For instance, conversing parties need to be able to support a given version of HTTP (e.g., HTTP 1.1.), or, in the case of messaging infrastructure, the messaging end points must be able to converse (e.g., Java messaging services (352)). The selection of a transport layer mechanism may be affected if security is required of the transport layer. For example, if parties required protection of data, they could accomplish this through the use of secured HTTP (HTTPS) as the transport mechanism.

• At the message layer, mechanisms that allow conversing parties to exchange messages that can be consumed and processed by endpoints (e.g., SOAP messages pertaining to a particular version of SOAP) are required. As with the transport layer, it is possible to implement security in the message layer. For example, if SOAP messages are being exchanged, part of the agreement may be that the message be protected through the use of standard SOAP signing (52, 321) or encryption (321, 383) mechanisms.

• At the services layer, each party must be able to specify its requirements and policies for quality of protection in order to engage in a secure conversation, and the requirements and policies expressed by different parties must be made mutually comprehensible. For example, in a service-oriented framework, resources are cast as services with service definitions (e.g., WSDL; see Chapter 17). These service definitions can be used to advertise the policies and requirements of the service, such as the fact that it accepts Kerberos credentials as a valid means of authentication. For example, policy and requirements can be stated using tagged components in the CORBA model or by WS-Policy expressions in Web service endpoints.

• At the policy layer, mechanisms to represent names are needed to facilitate the correct application of policies. Names of entities, services, resources, and operations are all expressed in policies and may be assigned by different authorities in different domains and asserted using different authentication mechanisms. For example, the policy statement “The Kerberos user Alice from domain XYZ is allowed to invoke method foo() on resource BigServer in domain ABC” requires that the policy creator and policy enforcer agree on how to express names and who assigns these names for entities (“Alice from domain XYZ”), operations (“method foo( )”), and resources (“BigServer in domain ABC”) so that they are unambiguous, consistent, and trusted.

21.1.3.2 Dynamic Trust Domains

The VOs that underlie collaborative work within Grids may form quickly, evolve over time, and span organizations. Their effective operation depends critically on trust, the extent to which one participant can rely on others to behave as expected (321).

In the simple case, personal knowledge between parties in the VO allows policies to be derived from identifiable trust “anchors” (parties vouching for other parties). An example in current Grid systems is the use of certificate authorities to root certificate-based identity mechanisms. For these to work, one must “know” about the trustworthiness of the certificate authority used to establish the identity of a party in order to bind it to specific usage policies. Although the direct expression of policies in terms of identities is a nontrivial task, progress in the expressiveness of policy languages may be sufficient to allow this.
 

<< 1 2 3 5 6 >>