Wide adoption of Grid technologies to build systems for scientific computing purposes introduces the need of a careful consideration of the possible security threats that systems based on these technologies are exposed to. Grid infrastructures are usually built upon public communication infrastructure therefore they are vulnerable to common attacks for the Internet world. The main types of security issues that Grid has to consider are architecture related, infrastructure related and management related [68]. Confidentiality of the data shared in the Grid environment and mechanisms to ensure authentication, authorization mechanisms for access to resources and quality of service related issues are part of the first category. The second category comprises security problems related
to host components and secure transport of data over the wire. The third one refers to problems related to credential management, trust and monitoring services.
Trust among the participants that share and access remote resources is a central concept of security and it is vital for Grid infrastructures. Virtual Organizations(VO) are estab-lished based on the willingness of resource providers to share their computing capabil-ities to other members of the VO. Reliable authentication mechanisms must therefore be enforced to ensure that users and resource providers cooperate in a secure environ-ment. The Grid Security Infrastructure (GSI) provided by Globus addresses these issues related to security and provides solutions for secure communication. Standardized secu-rity mechanisms enforced at Grid level ensure that secusecu-rity breaches are less frequent, easier to detect and address.
The communication among various partners of a VO built using Globus middleware relies to a great extent to HTTP and HTTPS communication protocols. Additional pro-tocols such as GridFTP may also be used for data transfer. The secure communication mechanisms implemented by Globus GSI implements secure communication by target-ing two communication levels: transport and message. Transport level security applies TLS encryption for all communication that is sent over the wire. This type of encryption guaranties confidentiality and authentication at least from the server side and optionally client authentication may also be enforced. Integrity of the messages exchanged is also ensured through transport level encryption. Message level encryption may be used to encode only the message content while the rest of the communication is transmitted as plain text and therefore confidentiality, authentication and integrity of the messages is ensured. If authentication of the client and integrity of sent messages are required while confidentiality is not mandatory a slightly more efficient solution is to send messages in plain text and to append digital signatures that guarantee the authenticity of messages and the identity of their originator. All these features are based on X.509 standard.
Currently the most popular and wide spread solution for users’ authentication in Grid en-vironments are solutions base on X.509 Public Key Infrastructure (PKI) [29], but other
standards such as Kerberos Network Authentication Services [138] or plain security cre-dentials management are also used. Anonymous authentication is possible especially when the client’s identity is not particularly relevant. Globus GSI provides native sup-port for authentication based on X.509 certificates but additional solutions that allow integration with Kerberos based systems are available. Since authentication of the actors participating in a distributed architecture can be achieved with different authentication protocols, e.g. Kerberos and PKI, an interoperability between such services may be sometimes required. A service responsible for providing a X.509 certificate based on a Kerberos authentication was previously reported in [30].
VOs can easily be built over a hierarchy of Certificate Authorities that guarantee au-thenticity of X.509 certificates exchanged amoung participants in the VO. The use of security certificates provides further functional benefits. Single sign-on, delegation of credentials and with them finer grained control over the identity of the users that are entitled to access specific hardware and software resources can be easier provided. Del-egation of credentials is particularly important mechanism if proxy components have to access secure services on behalf of a client. The proxy itself may not be entitled to access particular resources but while it acts on behalf of the client it may use its cer-tificate to access them. To support credential delegation Globus provides the Credential Management Service and the MyProxy component [45].
For Grid authentication purposes, each user has an X.509 certificate. This certificate could be stored on the user’s system, but this solution makes them vulnerable to theft by trojans or viruses. MyProxy acts as an on-line credential repository for X.509 security credentials which are composed of private keys and certificate tuple. Based on stored credentials MyProxy generates proxy certificates, all via a TLS secured network con-nections. Since proxy certificates expire after a relatively short period of time, usually 12 hours, the user must periodically renew them. The generated proxy is then stored in the repository and is accessible via (username, password) combination. The password is chosen by the user when first generates the proxy and has the same lifetime as the proxy certificate. Additionally, MyProxy can be accessed through the network from various
locations which proves to be an important advantage for mobile clients.
GSI offers implementations for both WS-Security and WS-SecureConversation. With the latter, a security context is established resulting better performance when multiple invocations take place among two communication partners. Credential delegation is only available if a security context is established through WS-SecureConversation. Au-thorization mechanisms implemented by Globus GSI can be applied at Globus container level, at service level and at resource level. The authorization scheme can be imple-mented through authorization descriptors or dynamic Java settings. The default autho-rization mechanisms can be extended by custom authoautho-rization handlers. An example of an extended authorization mechanism is provided by POSITIF [72].