| In this section, we will approach grid service security [5] with a detailed discussion on the security challenges faced by the grid community in general, and then explore the details of security solutions provided by the OGSA. Resource sharing among heterogeneous virtual organization participants is a complex process because of the challenges faced in integration, interoperability, and trust relationship. We can further explain this by examining the following factors: Integration Challenge. There are numerous security frameworks, comprehensive standards, and implementation available today. The majority of these organizations, individuals, and/or resources have their own preferences about the security requirements that are most suitable for their own environment. We cannot replace all these security frameworks, nor are we able to come up with a common alternative. This places the burden on the participants to honor the existing security frameworks and/or seamlessly integrate with them. This, in turn , requires that the OGSA security architecture be "implementation agnostic ," so that it can be instantiated in terms of the existing security mechanisms; that is, "extensible" so that it can incorporate new security services when available; and capable of integration with the existing security services. Interoperability Challenge. The resource sharing of these interoperable resources may extend into many domains of security realms, and their respective needs security interoperability at each layer of service implementation. Let us examine these various levels in the following points: -
At protocol level, different domains need to exchange messages across their protocol layers and they need to have interoperability at each layer of the protocol stack. -
At the policy level, secure interoperability requires each party to specify any policy it may wish to enact in order to enter into a secure conversation, and these policies need to be interoperable and mutually comprehensible. -
At identity level, we require mechanisms for identifying a user from one domain to another domain. For any cross-domain invocation to succeed in a secure environment, the mapping of identities and credentials to the target domain identity is absolutely required. Trust Relationship Challenge. The trust among the participants in a dynamic virtual organization is the most complex thing to achieve, and this trust must be evaluated for each session or request. This requires federation of a trust relationship among the participants. To summarize, for the security challenges in a grid environment, one must ensure the following points are addressed while categorizing the solution areas: -
Integration solutions where interfaces should be abstracted to provide an extensible architecture. -
Interoperable solutions, to enable services to invoke each other even when they are hosted by different virtual organizations with different security mechanisms and policy requirements. -
Define, manage, and enforce trust policies within a dynamic grid environment. Figure 10.8 depicts these security items. Figure 10.8. The categories of security challenges are complex in a grid environment.  Figure 10.8 emphasizes the security challenges we have discussed earlier in this discussion, and their solution dependency. As indicated by the relationship arrows, a solution within a given category will often depend on another category. OGSA Security Architecture The OGSA security architecture addresses the above problems and challenges through security mechanisms that are plug-and-play at the client and service side. These design points are discoverable by the service requester from a service description. The grid environment requires an OGSA platform security mechanism to support, integrate, and unify popular security models, mechanisms, protocols, platforms, and technologies. Common Securities Elements Required for a Grid Environment Authentication Provide integration points for multiple authentication mechanisms and the means for conveying the specific mechanisms utilized in any given authentication operation. Delegation Provide facilities for delegation of access rights from requestors to the services. These delegated access rights must be transferred to the tasks to be performed, and for a limited time, framed in order to limit the risk of misuse. Single Sign On This capability allows a service user to utilize multiple resources with one explicit logon process, and thereafter, automatically delegate the same authenticated credential for the next resource access without user intervention, within a specific period of time. These single-sign-on sessions may include accessing of resources in other domains using a service credential delegation. Credential Lifespan and Renewal Credentials have a limited time span associated with them, and most of the grid jobs may take more time to execute. This may cause credentials to get invalidated, rendering the system to an invalid state. In order to avoid this, a grid system must support credential expiry notifications to the users and credential revalidation facilities. Authorization This model allows for controlling access to OGSA services based on authorization policies (i.e., who can access a service, and under what conditions) attached to each service. In addition, it allows the requesters to specify invocation policies (i.e., to whom does the client trust to provide the requested service). Authorization should accommodate various access control models and implementations . Privacy Privacy policies may be treated as a type of authorization policy that brings privacy semantics to a service usage session. Similar to authorization, OGSA security must allow both a requester and a service to enforce privacy policies, for instance, taking into account things like personally identifiable information (PII), purpose of invocation, etc. Confidentiality Protect the confidentiality of the underlying communication (networking services transport) mechanism, and the confidentiality of the messages or documents that flow over the transport mechanisms in an OGSA-compliant infrastructure. The confidentiality requirement includes point-to-point transport, as well as store-and-forward mechanisms. Message Integrity This provides mechanisms to detect the unauthorized changes to messages. The use of message- or document-level integrity checking is determined by one or more policies, which are determined by the QoS of the service. Policy Exchanges Allow clients and services to dynamically exchange policy information to establish a negotiated security context between them. Such policy information will contain authentication requirements, supported functionality, constraints, privacy rules, etc. Secure Logging For nonrepudiation, notarization, and auditing; provide logging facilities for all secure conversations, especially logging negotiations. Assurance Provide a means to qualify the security assurance level that can be expected from a hosting environment. This can be utilized to express protection characteristics of the environment, such as virus protection, firewall utilization, internal VPN access, etc. Manageability Provide manageability of security functions, such as identity management, policy management, security key management, and other critical aspects. Firewall Traversal Security firewalls are present in most of the distributed systems network to prevent unwanted messages from entering into a respective domain. The grid, being a virtual organization, realizes firewalls may cause challenges on message transfers between participants. This forces the OGSA security model to circumvent the firewall protection without compromising the local host security. Securing the OGSA Infrastructure Securing the OGSA infrastructure secures the OGSI itself. The model must include securing components like Grid HandleMap, discovery service, etc. |
Security Services The OGSA security architecture has an insurmountable task of establishing a security model to capture all the above requirements. As a natural progression, the OGSA security architecture is aligned with the Web services security model. Figure 10.9 shows the security architecture model of the OGSA. Figure 10.9. The OGSA security architecture.  Figure 10.9 shows the core security models utilized in the grid environment. All grid services communicate with each other based on a set of bindings specified by the services. These bindings must deal with the security details including message confidentiality, integrity, and authentication. Normally speaking, these bindings are initialized on a runtime-based set of policies, specified by the service providers. These security policies can be specified as static documents, such as WSDL or WS-Policy documents, or can be negotiated at runtime based on the capabilities of the client and service. The common policies specified include supported elements such as authentication mechanisms, required integrity/confidentiality, trust policies, privacy policies, and security assertions (e.g., policy assertions). Once the grid service client and service providers discover the receptive security policy, they can then enter into a secure conversation mode and establish a secure channel for the messaging exchange. This channel must then also enforce all of the agreed-upon security QoS guarantees . Let us now explore the details of each of these components in more detail, and better understand the technologies of interest in each layer of the security component model. Binding Security The binding transport includes SOAP, IIOP, JMS, HTTP, and so on, and each of these transport protocols have different security requirements for authentication, message integrity, and confidentiality. For example, HTTP and SSL combined comprises " https " as its secure conversation channel, guaranteeing message integrity and confidentiality, yet with the limitation of a point-to-point protocol channel. This networking services protocol may also require higher-level coordination services for end-to-end flow across intermediaries (e.g., firewalls, proxy servers, etc.). In the case of SOAP messages, the WS-Security model [6] provides a secure message exchange pattern utilizing the SOAP headers as the security information exchange carrier. The integrity and confidentialities of SOAP messages can then be protected utilizing XML digital signatures and encryption standards, [7] and WS-Security then provides secured profiles for exchange of this information. Other binding level security infrastructure includes CSIv2 for IIOP-based communications adopted by CORBA vendors , and the J2ee 1.4 as a mandatory standard for secure IIOP messages. Policy Expression and Exchange In order for a secure message exchange to exist, both the service requester and service provider must agree on the certain policies for the receptive secure message and conversation to occur. This policy agreement can be accomplished a priori (i.e., static information) or at runtime (i.e., dynamic), and the best possible security binding selections must be performed at both the service provider and service requester sides of the conversation. The grid, being a highly dynamic environment, also requires dynamic policies and decisions to be executed at runtime. These dynamic policies can be associated with the service WSDL, service's service data, or can be exchanged through collaborative negotiations. In addition to the conversational requirements, there may often be a requirement for the respective policy information to be present in order to provide secure binding to native platform services. One of the notable technology candidates in policy exchange areas is WS-Policy, which specifies how service providers and service requesters can, in turn, specify their respective requirements and capabilities. At this stage of the discussion, we have explored the binding and policy exchange layers, which allows the service requester and service provider to discover the policies they require for a secure conversation to occur. The next layer is related to the nature and enforcement of these policies. That is, a secure association between service endpoints; mapping of identities and translation of credentials; and authorization policies and privacy policies, which provide access control to services. Secure Association In the grid context, the communications between a service requester and the service provider are oftentimes long-running conversations through various message exchanges. The OGSA security architecture specifies creating a secure context during the initial negotiation between the client and the service, while utilizing the same context for protecting the subsequent messages. The secure context is then coupled with networking services transport binding, and this concept is already available with most of the security protocols (e.g., SSL and IIOP-CSIv2). For the OGSA Grid Computing environment, the secure conversation support is provided using the WS-SecureConversation protocol. Recalling from an earlier chapter discussion, the WS-SecureConversation describes how a mutual authentication between service requester and service provider is accomplished and how to establish mutually authenticated security context. Identity and Credential Mapping/Translation A grid environment consists of multiple trusts (i.e., virtual organizations) and security domains. To cross the domain boundaries requires a mutual authentication. Therefore, a requirement exists to map and/or translate the credentials from one domain into another. This interoperation needs a "federation" of domains and their security mechanisms. This federation can be accomplished through the mapping and/or translation of identities and/or credentials from one domain to another utilizing some trusted intermediary services, gateways, or proxies. In the context of Web services, there is some ongoing work to define this federation message exchange pattern and model. The grid community of practitioners can expect the WS-Federation to become a published approach for OGSA-based grid services some time in the not too distant future. Authorization Enforcement Authorization to access a resource is controlled by policies enforced in the resource provider side of the environment. Today, there are several different commercial authorization mechanisms available across the industries. The most prominent ones are role-based authorization, rule-based authorization, and identity-based authorization. The selection of these mechanisms is entirely based on the service requirements, hosting platform capabilities, and the application domain (e.g., B2B, B2C, G2C, etc.). WS-Authorization provides more specific details on how access policies for grid services and Web services are specified and managed. In today's grid scenarios, most of the access to the resources is controlled, based upon the identity of the requester. This requires the resource to maintain an access control list (ACL) with the identity of the end user, or with the mapped identity of the end user. In the second case, a mapping or translation of identity must occur before the end user can access the resource(s). Privacy Enforcement Maintaining anonymity, or the ability to withhold private information, is one of the core requirements in many grid service environments. Organizations involved in the grid environment may need to declare their privacy requirements, and conversely may need to monitor the privacy policy enforcement results. The WS-Privacy specification provides mechanisms to describe a model for embedding privacy information and exchanging this information in conjunction with the messages. In the case of protecting privacy requirements, and declaring them to customers, the grid environment must adhere to the WS-Policy model, and therefore align with the W3C's P3P efforts. [8] Trust Every member of a VO is likely to have a security infrastructure that includes authentication service, user registry, authorization engine, firewalls, network-level protection, and other security services. These security policies are defined to the security domain in which they exist. This self-containing security model requires a trust among the VO members before they can access the above services. This trust relation can be called "membership in the VO" and will enable a set of policies among the VO participants, identity and credential mapping policies, and/or a membership with the trusted party through some proxies or gateways. The grid trust model is based on the WS-Trust specification. Core Security Services for OGSA In previous sections of the book we have discussed the security features and these requirements for a grid environment. We have discussed how we can achieve many of these security requirements, and the specific details of each of the security models. We have already noted that in a grid domain, the interoperability and integration among the existing security technologies is an absolute requirement. In order to achieve these aforementioned capabilities, the OGSA grid security standard has defined a set of abstract services on the top of the existing security platforms and framework. These services are exposed through the WSDL. Figure 10.10 details the OGSI security platform services and their relationship with other OGSA components. Let us now explore the possible OGSA security service candidates in greater detail: -
Authentication service. Validates the service requester's identity. One example can be the basic authentication mechanism where user identity and password are validated within the user registry. -
Identity mapping service. Provides an identity mapping function where one service's identity can be mapped to another service's identity in another domain. These services are not concerned with the authentication to the service. -
Authorization service. Resolves the request to access a service by verifying the access policies associated with the requester. The OGSA security service relies on the hosting environment's access control mechanisms using the service requestor 's identity and policies associated with the service. -
Virtual organization policy service. The OGSA security service can utilize the OGSA policy framework in order to provide policy storage, policy enforcement, and policy validation. -
Credential conversion service. Responsible for the conversion of user credentials to another type and/or form of credentials. -
Audit service. Responsible for producing the records of the security activities and logging them based upon the specified policies. -
Profile service. Concerns the creation and storage of profiles, including personalization data. -
Privacy service. Concerns the policy-driven classification of PII. These services can be utilized to enforce the privacy requirements for a service requester and provider. Figure 10.10. The OGSA Platform security components.  Summary In summary, the grid security model must be able to leverage these existing security standards for their QoS requirement on secure message exchange. The OGSA security architecture asserts that the OGSA security model needs to be consistent with the Web service security model. Many practitioners in the Grid Computing discipline believe that the WS-Security model, and its core components, are going to become the default standard for interorganizational and interenterprise secure messaging exchange brokering services. This WS-Security model is not simply limited to SOAP bindings, and can always be extended to any message protocols that can exchange XML messages, while having an associated information model. |
