Grid Security Infrastructure

The Grid Security Infrastructure (GSI) [37] is the security framework underpinning the Globus Toolkit middleware [59] and provides various security functionality to support Grids. The current incarnation of the Globus middleware is based on Web Services technologies. GSI is the most commonly used security infrastructure on the Grid. It contains four primary functions: authentication, authorisation, delegation and message protection.

As shown in Figure 2.6 Authentication is performed using X.509 digital certificates or user- name/password pairs as credentials. X.509 credentials allow for the use of advanced security features such as delegation, confidentiality and data integrity. The username and password option does not support such features. However, through other solutions such as MyProxy [65], username and passwords can be used to access MyProxy repositories to create short lived proxy (X.509) certificates.

GSI implements an Access Control List (ACL) in the form of a grid-mapfile, which is used to control access to resources. A grid-mapfile contains a list of mappings between local user accounts and Distinguished Names (DN) of pre-accepted X.509 entity certificates. The list determines who can access services or resources on the host/container and the privileges of the host’s mapped local accounts. This controls access on a per container or per Unix account privileges and not on a per service or per service-method basis. In some cases this kind of access control is sufficient, but is not in many other cases such as the service-oriented cases. The current version of GSI uses the SAML standard for providing AuthorisationDecision assertions as a means of exchanging user’s attributes from clients to services, this is used by most CAS clients. It also uses the AuthorisationDecision protocol of SAML to support integration of other authorisation decision services, such as PERMIS.

GSI provides message protection by communicating SOAP messages [66] over Transport- Level Security (TLS) or encrypting portions of SOAP messages using WS-Security standard or the WS-SecureConversation specification for Message-Level Security (see Section 2.4.4). In contrast to TLS which uses X.509 credentials to establish secure transport layer connections, MLS uses X.509 credentials to either establish a session key or uses the associated keys of the sender and receiver’s X.509 credentials for message protection.

Whilst widely accepted, GSI has several issues including a lack of scalability owing to the use of grid-mapfiles and lack of inherent fine-grained access control. However, fine-grained access control could be achieved with the use of third party authorisation services such as PERMIS in combination with GSI.

2.4 Security Standards in Federation Systems

This section reviews some evolving security standards that underlines the exchange of secu- rity information in decentralised open environments. Key to this is federation. Organisation for the Advancement of Structured Information Standards (OASIS) considers Federation

[67] as a term for organisations that collaborate based on agreed standards and that com- bine business and technological practices to enable access to resources and services across boundaries in a secure and trustworthy way. A federation is built based on trust, standards and agreements [68, 69]. Today, a federation is often associated with single sign-on (SSO) across organisational boundaries [70, 71]. SSO enables a user to authenticate once at the beginning of a process or computation and then to be automatically authenticated to every other process or computation that the user or process initiates. Users do not have to keep multiple passwords and they do not have to keep authenticating themselves every time access is required to other processes, services or resources.

2.4.1 Security Assertion Markup Language

Security Assertion Markup Language (SAML) [72] is a standard developed by OASIS to provide a means of exchanging security-related information between parties over the net- work. The standard provides a communication framework written in XML for the exchange of assertions between (virtual) domains. This framework does not define new mechanisms for authentication or authorisation but enables existing security mechanisms to interoperate across boundaries. One of the SAML components called Assertions provides security informa- tion consisting of user authentication (identity), attributes and entitlements. SAML allows domains to collaborate and make decisions based on signed assertions. As shown in Figure 2.7, SAML components include Protocols [70], Bindings [73] and Profiles [74]. The XML rep- resentation of SAML makes it in principle interoperable and easy to integrate into existing applications; flexible and extensible with other standards such as Shibboleth, WS-Security [75] and PERMIS.

The SAML specification defines how to construct, exchange, consume, interpret and extend security assertions for various needs. Key benefits of the specification include: interoper- ability; loose coupling of resources; improved end user experience; risk transference, and a reduced administrative costs for service providers [76].

SAML contemporaries include Liberty Alliance [77] and WS-Federation [69]. To bridge the gap between these different federated protocols, federation gateways [78] are being suggested to act as brokers between the different evolving federated identity management protocols. The word “evolving” is to indicate the incompatibilities that exist presently between protocol versions.

Figure 2.7: SAML Overview - Push Scenario

September 2003. SAML 1.0 addressed how identity information and be communicated from one domain to another. While SAML 1.1 adds support for “network identity”, secure ex- change of user security information between organisations and introduces signing of SAML assertions by the use of digital certificates. In March 2005, SAML V2.0 [70] was approved as a standard and appears to be a step closer to full convergence of federated identity stan- dards. SAML V2.0 comprises input from Shibboleth and Liberty Alliance’s Identity Federa- tion Framework (ID-FF) 1.2 [71]. SAML 2.0 consolidates protocols for single sign-on, policy management and delegated administration. SAML 2.0 enhancements include support for federated identity, global sign-out and session management. Typical uses of SAML includes [80]:

• Web-based single sign-on (Authentication) including communication of authentication assertions from one site to another;

• Attribute-based authorisation and use in Shibboleth for attribute exchange;