Security in Distributed Systems – A look at Globus Stephen Rook srook1@umbc.edu December 4, 2007 Overview Background – security’s role in distributed systems Overview of Globus Globus Security Policy Globus Security Architecture Questions 2 Background Security Overview Why do we need to consider security issues for distributed systems? The main goal is to protect the system and its resources from unauthorized use. Authentication Ex: Is “Adam” truly Adam, an employee in good-standing of a company’s branch in New York, or is “Adam” truly Damien, a recently fired employee whose ultimate goal is to take down the company server? Authorization Ex: Does Adam have write privileges on a file foo.txt located on the company’s Los Angeles server? 4 Security Overview (2) Why is it so difficult to implement security on distributed systems? Resources can span many geographic domains. The system must keep track of where its resources are located Ex: An employee on subnetwork A in the U.S. wishes to access a file stored on the company server on subnetwork C located in Germany. For some resources, only certain classes of users can be allowed access. Falls under the authorization domain Ex: Suppose we have two low-level employees, John and Sam. John should not be able to access Sam’s employment record even though they both work for the same company. However, Sam’s supervisor should have access rights. 5 Security Overview (3) Most distributed systems are heterogeneous They are comprised of mixed types of computers and resources Ex: Grid systems Need to define protocols to safely access system components no matter where such components reside 6 Globus Overview Globus Proposed by Foster, Kesselman, and Tuecke in 1998 Version 0.1 (the first) was implemented in April 2000 Version 4.1 was released September 2007 Designed for grid computing Security of the vast number of components in the entire system is the prime concern 8 Implementation – Earth System Grid (ESG) A distributed system that stores and provides a wealth of climatology data to users. Some services require authorization and thus users must be authenticated. Problem: With so many user accounts, how to ensure that authentication works correctly while allocating the majority of processing time to the multitude of data requests? Solution: Use global authentication as provided by the Globus toolkit. Once authenticated globally, a user is free to use the subsystems/services that he/she is authorized. Will return to this point later. 9 Overview Background – security’s role in distributed systems Overview of Globus Globus Security Policy Globus Security Architecture Questions 10 Globus Security Policy Globus Security Policy Security Policy: a collection of general statements that detail the critical components of a system and how these components should be protected. Effective security mechanisms require a comprehensive and well-designed security policy. Globus’ security policy consists of 8 statements/assumptions. 12 The Global System Consists of Multiple Subsystems (#1) Multiple existing disjoint subsystems (most likely heterogeneous) need to be seamlessly integrated under a minimal number of standardized security protocols. Ex: Suppose that companies A, B, & C, offering the same service, have merged after independently operating for years. Now suppose that the 3 companies have merged and wish to integrate their websites. Most likely, each website is managed by a different security policy and has different critical resources. The goal is to integrate the subsystems in such a way so that membership in the global union does not override the local security policy of any subsystem. Thus, the global authority need only consider actions that span multiple subsystems. 13 Figure 1. (Left) 3 subsystems that run independently of each other. (Right) The same 3 subsystems connected to a global authority (G) . The functionality of the 3 subsystems should change very little if at all even though they are now connected through the global authority. 14 Local Operations are Subject to Local Security Policies Only (#2) Complements the first assumption. Ex: Suppose that an entity in domain B wishes to utilize a file housed in domain B. Local operation. Just as if domain B was running independently of Globus and any other subsystems. Globus should recognize local operations and not impose further restrictions. 15 Global Operations (#3) Operations that affect more than 1 domain in the distributed system. Require the initiator to be known in each domain where the operation is executed. Ex: If Adam wishes to update a file located in domains A, B, and C, each domain must authenticate him before he can be allowed to perform the update. 16 Operations Between Entities in Different Domains (#4) Requires mutual authentication by both domains. Extends the previous statement in both directions. Ex: Suppose Adam located in domain A wishes to use a mail server located in domain B. Not only must Adam be authenticated by domain B to use the mail server, but the mail server must also be authenticated by domain A. The latter condition ensures Adam that he is indeed using the mail server from domain B and not malicious software. 17 Global Authentication Replaces Local Authentication (#5) With many users, authenticating each resource request locally makes scalability impossible. Global authentication by Globus supersedes local authentication. Improves performance of the distributed system. Ex: Suppose Adam located in domain A wants to perform operations in domains B and C. Adam must be authenticated in domains B and C. Instead, allow Globus to globally authenticate Adam. Adam can now be considered authenticated in domains B and C if both domains recognize Adam. Recognition takes less processing time than authentication. 18 Controlling Access to Resources (#6) Subject to local security only. Globus would become overwhelmed if it had to track the security status of the numerous resources. Ex: Suppose Adam located in domain A wishes to modify a file located in domain B and has already been globally authenticated. Even though Adam has been authenticated, his access rights to the file still must be checked. Access rights are checked by the file’s local domain – in this case domain B. 19 Users can Delegate Rights to Processes (#7) A user should be able to copy his/her authentication and access rights to created processes. Ex: Suppose that Adam located in domain A has been globally authenticated. He wishes to deploy processes P1 and P2 to repeatedly poll files located in domains B and C respectively. Adam can pass his authentication certificate to processes P1 and P2. P1 receives access rights for the files needed in domain B and P2 receives access rights for the files needed in domain C. 20 Users can Delegate Rights to Processes (continued) Globus globally authenticates the processes (verifying that they are from Adam). The processes can then begin working in their respective domains as if they were Adam himself. Efficient for processes that initiate many remote operations. Otherwise, domain B would have to contact Adam for authentication EVERY time that P1 initiated an operation. The communication cost for this persistent validation may prove to be prohibitive especially if domains A and B are great distances apart. 21 A Group of Processes in the Same Domain can Share Credentials (#8) Multiple processes attributed to a single user located in a remote domain can share one set of authentication and access rights. Known as credentials. Ex: Suppose Adam located in domain A has multiple processes P1, P2, and P3 operating in domain B. The 3 processes share a set of credentials. Credentials are easily modified even if there are a large number of processes. Easily scalable – space is conserved since only one copy of the credentials need be present per domain. 22 Globus Security Architecture Globus Architecture Overview Assumes that local resources are protected by the local security policy. Globus need only mediate when requests span multiple subsystems. Important implementation issues: How a user is represented in a remote domain. How remote resources are allocated to users. 24 Globus Architecture Overview (continued) Globus architecture is described using entities: Users User proxies: processes that are given permission to act on behalf of a user temporarily. Resource proxies: processes used to translate a remote user’s requests into operations that do not violate a resource’s local security policy. General processes Globus has defined four protocols using entities. Consistent with the aforementioned security policy. 25 Creation of a User Proxy & Delegating User Rights (#1) First, a process is created by the user in his/her local subsystem. To act as the user, the process must be given an identifying key linked to the user. This key is a tuple comprised of the user’s id, name of the local host, authentication lifetime, etc. The user then digitally signs the tuple, indicating the validity of the proxy to remote domains. The proxy is then provided with the key and allowed to execute in a remote domain. It is the responsibility of the local security policy to protect this key. 26 Requesting the Allocation of a Remote Resource (#2) A user proxy (UP) locates the resource proxy (RP) for the resource it wishes to access. The UP and RP authenticate each other. The RP checks if the resource is available. If the request can be honored, the RP allocates the resource to the UP. Otherwise, the RP denies access and it is up to the UP to try again after some specified passage of time. 27 Allocation of a Resource by a Remote Process (#3) Essentially follows the second protocol. Ex: A resource allocated to a UP may spawn process Pα that requires an additional resource R1. The request to R1’s RP must come from the UP, NOT Pα. Advantages: Simplicity and greater security. Allowing only UPs to initiate resource requests decreases the potential locations for security breaches. Disadvantage: scalability is limited due to a single point of requests (UP). 28 Recognizing a User in a Remote Domain (#4) First, the user authenticates globally with Globus. A subsystem-wide mapping of the global authentication to a local authentication is accessible by the RP. The exact implementation varies with each domain. Examples include trees and linked lists. The user is considered authenticated for domain X if the RP can find a mapping from the user’s global authentication to his/her local authentication for domain X. The remote domain thus recognizes the user. 29 30 References 1. 2. 3. 4. Tanenbaum and Van Steen. Distributed Systems – Principles and Paradigms. 2nd ed. 2007. Foster and Kesselman. “Globus: A Metacomputing Infrastructure Toolkit.” 1996. Foster et al. “A Security Architecture for Computational Grids.” 1998. Globus Alliance. http://globus.org. 31 References 5. Earth System Grid. http://earthsystemgrid.org. 32 Questions? 33