'u'|[|l‘ I- -l -ur ' | Fl T) ,. r ..‘ S Li zit/IN fl Libi—‘rA'RY Michigan State University This is to certify that the thesis entitled ACCESS CONTROL IN MANUFACTURING INFRASTRUCTURE AND DESIGN AUTOMATION SYSTEM presented by YUAN ZHANG has been accepted towards fulfillment of the requirements for the Master of degree in Department of Computer Science Science and En ineerin \ _--' ' q‘7QC9Maj{pp/:fessoéfinat““ax‘ '3 00 Date MSU is an Affirmative Action/Equal Opportunity Institution PLACE IN RETURN BOX to remove this checkout from your record. TO AVOID FINES return on or before date due. MAY BE RECALLED with earlier due date if requested. DATE DUE DATE DUE DATE DUE 6/01 cJCIFICIDateDuepes-p. 1 5 ACCESS CONTROL IN MANUFACTURING INFRASTRUCTURE AND DESIGN AUTOMATION SYSTEM BY Yuan Zhang A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Department of Computer Science and Engineering 2003 ABSTRACT ACCESS CONTROL IN MANUFACTURING INFRASTRUCTURE AND DESIGN AUTOMATION SYSTEM By Yuan Zhang More and more information is generated and stored in Virtual Enterprise systems, and at the same time the system designer cannot assume that the system users are trustworthy, so that the security issues must be considered when a new Virtual Enterprise system is designed and developed. In MIDAS, a new backbone of Virtual Enterprise systems, the security is always concerned even in the design stage of the system. In this paper, we explain what security means to a Virtual Enterprise system, and introduce three basic components (authentication, access control and auditing) of an entire security subsystem. The access control component is discussed in detail. And different access control low-level mechanisms and high-level models are examined. According to the security requirements in the collaborative environment and the drawbacks of the Classical access control models, we propose a new access control model: Layer-based Access Control (LBAC), and implement LBAC in MIDAS. Table of Contents List of Figures .................................................................................................... vi List of Tables ..................................................................................................... vi i List of Lists ....................................................................................................... viii Chapter 1 Introduction ....................................................................................... 1 1.1 CAD/CAM Systems .................................................................................. 1 1.2 Digital Factory ........................................................................................... 2 1.3 Virtual Enterprise ...................................................................................... 3 1.4 MIDAS ...................................................................................................... 5 Chapter 2 Security of Collaborative Environment _ .................. - 8 2.1 Collaborative Environment ....................................................................... 8 2.1.1 Coordination Theory ................................................................................. 8 2.1.2 Additional Functions ............................................................................... 12 2.2 Security of Collaborative Environment .................................................... 14 2.2.1 Access Control ........................................................................................ 15 2.2.2 Authentication .......................................................................................... 18 2.2.3 Auditing ..................................................................................................... 20 Chapter 3 Access Control ............................................................. - _ 22 iii 3.1 Access Control Mechanisms .................................................................. 23 3.1.1 The Access Matrix .................................................................................. 23 3.1.2 Access Control Lists ............................................................................... 25 3.1.3 Capability Lists ........................................................................................ 26 3.1.4 Authorization Relations .......................................................................... 27 3.2 Access Control Policies .......................................................................... 28 3.2.1 Discretionary Access Control ................................................................ 29 3.2.2 Mandatory Access Control .................................................................... 30 3.2.3 Role-based Access Control ................................................................... 32 3.2.4 Layer-based Access Control ................................................................. 37 3.3 Related Research ................................................................................... 48 Chapter 4 Manufacturing Infrastructure and Design Automatlon System (MIDAS) -- 52 4.1 Formal process grammar ....................................................................... 52 4.2 Collaboration in MIDAS .......................................................................... 60 4.3 The System Structure of MIDAS ............................................................. 64 Chapter 5 Security Implementation In MIDAS._ ..... -- __68 5.1 Authentication in MIDAS ......................................................................... 68 5.2 Access Control in MIDAS ....................................................................... 73 5.2.1 Basic Security Elements in MIDAS ...................................................... 73 iv 5.2.2 Access Control Models in MIDAS ........................................................ 79 5.2.2.1 Access Control in the Single User Execution Mode ............... 82 5.2.2.2 Access Control in the Collaborative Execution Mode ............. 92 Summary ......................................................................................................... 1 15 References ...................................................................................................... 1 17 List of Figures Figure 2. 1 three elements of access control ...................................................... 16 Figure 2. 2 structure of security system .............................................................. 17 Figure 3. 1 the organization structure of companyA ........................................... 38 Figure 3. 2 the hierarchical structure of project “bicycle design” ......................... 40 Figure 3. 3 the layer mapping between organization and project ....................... 42 Figure 3. 4 access control in the lowest layer ..................................................... 44 Figure 3. 5 access Control between different layers ........................................... 45 Figure 4. 1 basic objects in MIDAS ..................................................................... 55 Figure 4. 2 an example process flowchart .......................................................... 56 Figure 4. 3 a logical task and related productions ............................................... 59 Figure 4. 4 the process flowchart after applying a logical task ............................ 63 Figure 4. 5 the distributed structure of MIDAS .................................................... 64 Figure 5. 1 authentication in MIDAS ................................................................... 69 Figure 5. 2 Classes used to represent the objects in MIDAS .............................. 80 Figure 5. 3 Check permission ............................................................................ 100 vi List of Tables Table 3. 1 an example of access matrix ............................................................. 23 Table 3. 2 an example of ACLS ........................................................................... 25 Table 3. 3 an example of Capability List ............................................................. 26 Table 3. 4 an example of Authorization Relations ............................................... 27 Table 5. 1 basic objects and related actions in MIDAS ....................................... 75 vii List 5. List 5. List 5. List 5. List 5. List 5. List 5. List 5. List 5. List 5. List of Llsts 1 a user list ............................................................................................... 71 2 a permission list .................................................................................... 85 3 a list of new objects after applying a logical task ................................... 86 4 a new permission list after permission setting ....................................... 88 5 after the owner Changes permission list ................................................ 92 6 an assigned job list ................................................................................ 97 7 a contract ............................................................................................ 102 8 permission list with info of a contract ................................................... 105 9 an example of received project list ...................................................... 110 10 an example of given project list ......................................................... 111 viii Chapter 1 Introduction Never doubted that computer-related technology is Changing the whole world, especially for manufacturing industries that receive many benefits from computer-related technology. 1.1 CAD/CAM Systems ln1957, PRONTO, the first commercial numerical-control programming system, was published. From then the computer started to help the industry on design and manufacturing [Bozdoc]. After that several CAD/CAM (Computer-aided Design/Computer-aided Manufacturing) systems were developed. The CAD systems helped users create/modify the designs of products, and provided a 20/30 environment to display the models designed by users. The CAM systems focused on controlling machines to fabricate the products according to the designs generated by CAD systems. More and more data was provided by the CAD systems, so Computer-integrated Manufacturing (CIM) emerged to help the users organize the data generated by CAD system in the CAM environment [Bozdoc] 1.2 Digital Factory Later in the 1990’s, SD virtual modeling techniques were adopted by CAM, and the designing and manufacturing tightly integrated. Some new terms, Digital Factory, Digital Manufacturing and Virtual factory, were coined to describe the new systems [Donald, Andreou et al.; Freedman; Zha]. The early virtual manufacturing systems [Bayliss, Bowyer et al.; Gaines, Norrie et al.] integrated computer-based system design, production engineering and production subsystems into a framework. The framework provided the capabilities of recording and tracing decisions that were made within the production process stages. The Digital Factory integrates designing, manufacturing and assembling processes, and provides a complete environment where the designer can experiment with different manufacturing and assembling techniques [Bowyer, Bayliss et al.]. The Digital Factory is not only a simulator of the real workshop, but also is an effective integrated system of designing, manufacturing and assembling. It can help the designer quickly correct any unfeasible product design by Showing potential faults that can occur in the fabrication or assembly procedures. It also helps the designer generate a better/more complicated product design, a more efficient manufacturing/assembling process Simultaneously. In a Digital Factory system, the designer can modify the original design and see the Change in the final product in a Short time and without really generating the actual product. The Digital Factory shortens the time from design to market and reduces the design cost. By using the Digital Manufacturing NX system from Unigraphics [EDS], in 2001, General Motors saved $1 billion of costs and cut its vehicle product-development cycle to 24 months (before using the system, the development lead time is 54 months). [USBusinessReview]. Not only does the designer receive benefits from the Digital Factory, but the manufacturers do also. The Digital Factory is a virtual environment of the real work Shop, inside the environment workers can try any available techniques to fabricate the product without really starting a machine and trying the real material. It helps the worker to find a better way to fabricate the products. Also the Digital Factory system can be used to train new workers. 1.3 Virtual Enterprise But the Digital Factory systems are limited by their focus on the technique level to provide more functions of making designing/manufacturing/assembling easier. The Digital Factory systems are better suited in a Simple manufacturing environment. When the company becomes big and complex, and a working project is related to different departments, the Digital Factory systems need to be extended to a new level, because the collaboration requirement is beyond their capabilities. To efficiently integrate all techniques used by different units in a company, making different individuals/units collaborative becomes more and more important. To represent the collaborative environment, a new term “Virtual Enterprise” was created. In the Virtual Enterprise the techniques provided in the Digital Factory for individual units eventually can be used together to improve current manufacturing industries. There is no a common definition of the Virtual Enterprise. The NIIIP project defined a Virtual Enterprise (VE) as “a temporary consortium or alliance of companies formed to share costs and skills and exploit fast-Changing market opportunities [NlllP].” Walton and Whicker’s definition is that a “Virtual Enterprise consists of a series of cooperating ‘nodes’ of core competence, which form into a supply Chain in order to address a specific opportunity in the market place Melton and Whickerl.” Rahwan etc defined it as “an organization of enterprise sharing resources and working cooperatively towards the achievement of mutual benefit [Rahwan, Kowalczyk et al.; Argus-Systemsj.” Virtual Enterprise is Closely related to e-commerce, supply Chain management, and virtual corporation. The Virtual Enterprise emphasizes the relationship between different individuals/units who are in the Virtual Enterprise, so dependencies are the key to developing a Virtual Enterprise system. 1.4 MIDAS Manufacturing Infrastructure and Design Automation System (MIDAS) proposed in 1995 [Baldwin and Chung] is a framework, which integrates the Digital Factory and the Virtual Enterprise together. Basically MIDAS is an extendable process management system, which will be a backbone of the future automatic manufacturing system. MIDAS can adapt and control the existing Digital Factory and CAD/CAM systems, which are treated as external tool kits by MIDAS. Interacting with existing Digital Factory systems, MIDAS can automatically help the designer find the best design and manufacturing process. On the other hand MIDAS does not depend on any Virtual Enterprise systems, and it provides all fundamental functions of Virtual Enterprise. So MIDAS can be easily tailored to suit different companies to satisfy their different designing/manufacturing requirements. Since more and more data are generated, stored, and used by computer systems, the system security becomes more important than before. The early Virtual Enterprise systems mainly focused on how to easily make different units collaborate efficiently, and did not pay too much attention to the importance of security. In the real design and manufacturing environment, the users are not trustworthy, so the security must be considered when a new Virtual Enterprise system is designed. In the new generation MIDAS, the security is always engaged even during the system design time. In addition every module in the system is designed based on certain security requirements. The security subsystem is no longer a plug-in component to the whole new MIDAS. It is a fundamental subsystem, and all other components are built on it. This subsystem design is more secure than a plug-in system, because security mechanisms in a given system layer can be compromised from a layer below. To evaluate security, security mechanisms must be Checked and prove that they cannot be bypassed. The more complex a system, the more difficult this Check becomes. Usually the lower the layer of a system, the simpler is the layer structure. If security mechanisms are built into the lower layer, the security mechanisms will be Simpler and will be amenable to a thorough analysis. [Gollmann] In this paper, the author will discuss how to design a system with security concerns as primary, and how to provide fundamental functions to support collaboration in a virtual enterprise. A new access control mode, Layer-based Access Control (LBAC) model, iS proposed and implemented in MIDAS Chapter 2 Security of Collaborative Environment 2.1 Collaborative Environment To be a Virtual Enterprise system, MIDAS should support the basic functions that are fundamental to the Virtual Enterprise. So it is necessary to introduce basic theories of Virtual Enterprise. The main focus of the Virtual Enterprise is to provide an environment in which the different units efficiently collaborate with each other. First identifying relationships among the collaborating units is necessary. These relationships actually describe the dependencies between the units. 2.1.1 Coordination Theory To explore these dependencies in the Virtual Enterprise, Malone and Crowston proposed “Coordination Theory" [Malone and Crowston], which refers to the theories of how coordination can occur in diverse kinds of systems. They defined coordination as managing dependencies. To manage dependencies, we need to characterize different kinds of dependencies and identify the coordination processes. Three basic relationships that we need to understand before we develop a coordination system. follow: 1. Sharing resources Sharing the same (limited) resources is common in a coordination system. In the real manufacturing environment, no resource is infinite. When the requests of a resource are more than the quantity available, Sharing dependence occurs. For example, if two lathes are available, and three lathe operators want to use them at the same time, the coordination system must provide a way for the three operators share the two lathes. There are several strategies to handle this dependency: such as “first come/first serve”, “round robin” and “market-like bidding”. a. “First come/first serve” means when the first operator is using the one lathe, and the second operator is using the other lathe, when the third operator comes, he must wait until one of the two operators complete their jobs, than he may use the available lathe. b. “Round robin” is a solution if machines support a time sharing operation. “Round robin” means that the operation time of each machine is partitioned into several time slots. Within each time slot, one operator can use the machine. When the time Slot expires, the current operator must pause his work and let the next operator use the machine. All operators use the machine in turn. C. “Market-like bidding” also can be used to Share limited resources. That means the operator who pays the most has the first priority to use the machine. 2. Producer/consumer relationships “Producer/consumer” relationship is another common kind of dependency between tasks. It describes a Situation where one task produces some products used by another task. This relationship can be found in any manufacturing process. This relationship includes several kinds of dependencies: a. Prerequisite constraints refer to the producer task being completed before the consumer task can begin. A notification mechanism is used to handle this dependency. The consumer task is informed after the 10 producer task iS completed. Sequencing and tracking are the strategies used here. . Transfer means when one task generates a product used by another task, the product must be transferred from the “producer” to the “consumer". When the product is a physical one, such as a car, it is called transportation. When the product is a piece of information, it is called communication. In the Virtual Enterprise system, transfer usually refers to information communication. The common approach to information communication is to place a buffer between two tasks and allocate Space in the buffer to one process or another. . Usability is concerned about whether products can be consumed or not when the “consumer" receives them from the “producer". There are several ways to guarantee the usability. The first solution is standardization, meaning, defining a uniform interchangeable format that users already expect. The second way is to ask users what format they want. The third way is participatory design, which means the “consumer" actively participates in the design, while the “producer’ negotiates the format. 11 3. Simultaneity constraints Simultaneity constraints are another common kind of dependency among tasks. It represents that the tasks need to occur at the same time or not. Synchronization is the basic way to manage the Simultaneity constraints. 2.1.2 Additional Functions These three dependencies mentioned by coordination theory must be supported by the Virtual Enterprise. Terzis and Nixon pointed out other functions, which also should be provided [Terzis and Nixon]: 1. Dynamic group membership. To start a new project, first a supervisor selects a group leader and asks him/her to create a new group for the project. The group leader hires the people he needs to work together as a group on the project. The leader can hire/fire any group member from time to time, and a member may join/leave the group, so that the membership of a group is dynamically Changed. To provide a collaborative environment the Virtual Enterprise system needs to support these kinds of dynamic change. 12 2. Dynamic organizational and geographical group member distribution. In modern industry, to reduce the costs, a company usually distributes its departments across the world. For example, In the Nike 00., major departments are located in different countries and may be easily relocated. Its design department is located in Europe, and its manufacturing factory is located in China, and marketing department is in USA. All of those departments are also dynamically Changed. For example, Nike Co. could build a new factory in Malaysia or establish a new marketing department in Europe etc. All of those departments need to be coordinated smoothly to work as a whole company. Supporting organizational and geographical distribution is an essential requirement of a Virtual Enterprise system. 3. Dynamic modes and different ways of communication, Effective communication is one of the most important components of an enterprise. All the collaborative activities need to communicate with each other based on certain functions. Traditionally the individuals/units communicate though mail, telephone, and face-to-face meeting. The computer technology provides lots of new ways for communication, such 13 as online Chat (MSN messenger, Yahoo ICQ), e-mail, VolP (Voice over IP). High-tech based techniques make communication easier and faster. They dramatically reduce travel expenses and time. A Virtual Enterprise system needs to provide the right communication way at the right time for the right purpose. All of the functions mentioned are fundamental to understanding how to provide a collaborative environment, but one thing is missing. That is security. In the real design and manufacturing environment, the Virtual Enterprise system is big and complicated with a large number of users. We cannot assume all users are trustworthy. So when a Virtual Enterprise system is built, security must be considered. 2.2 Security of Collaborative Environment Security is a very broad concept. It covers from enterprise hardware to software, from physical resources to human beings, from low-level security mechanisms to high-level security policies. This paper only deals with about a small part of security — access control. 14 2.2.1 Access Control Resource Sharing, information transferring, group membership dynamically Changing, and system distribution all are related to - “access control”, which must be considered when a new system is designed. What is “access control”? Access control deals with how security systems control users’ access to environmental resources. The procedure to build an access control system actually is the procedure to answer the question: “Who can perform what actions on which information?” [Ferraiolo, Cugini et al.] This question describes all fundamental concerns of access control. Before considering this, three basic components must be understood: “who”, “which” and “what"? “Who” represents the subject of access control. The subject performs the actions. In the real manufacturing environment, “who” usually refers to a worker or a program “on behalf" of a worker. “Which” represents the object of access control. The object is the one on which the action is performed. Usually the object refers to the data, information or products. “What” refers to the action itself in access control. Actions connect subjects and objects together. The actions could be “read”, “write”, “transfer" or “consume”. 15 Using a UML [OMG] diagram, the relationships of the three components is showed as follow: Subject 1 * access 1 * Object . Name: String " " Name: String 1 * Action Name: String_ Figure 2. 1 Three elements of access control In mathematics access control can be defined as: Result = AC(S, A, O) Where AC() is a function of access control, the simplest result of the function is “yes/grant” or “no/deny". S is the subject, A is the action, and O is the object. The main work of access control is to solve the function. But access control cannot work alone to provide a full package of security functionality for a system. It relies on and coexists with other security services in a distributed system (Figure 1). The major concern of access control is to limit the 16 activity of legitimate users. An access control subsystem (or environment) provides a monitor to mediate every attempted access initiated by a user to the objects in the system. Whenever the monitor detects the access, the access control system consults an access database to determine that the attempted access is allowed or denied. Admin User DB I a User Authentication Monitor Authorization Objects Figure 2. 2 Structure of security system Typically, there are two other security services related to access control. They are authentication and auditing. Figure 2.2 Shows the logical relationship among access control, authentication and auditing. They interact with each other to 17 provide a secure environment. By using user infomlation databases, the authentication service proves the user is who he Claims to be. The auditing service monitors and records the access activities in the system. 2.2.2 Authentication Authentication and access control are very different. Authentication responds to identify users of the system. Authentication usually is done in the phase when the user checks into the system. Within access control phase, it is assumed that the authentication of the user has been verified. The access control service only deals with granting or denying the legal user’s access request. For example, a user wants to use a UNIX system, first he needs to correctly input the usemame and password, so that he can log on as a legal user. This step is called authentication. After successfully Checking into the system, each user is identified by his usemame. When the user wants to execute a program, he needs to send an executing command to the system. The command will be captured by the access control monitor, then the access control service will check the access database based on the usemame and command. According to the information stored in the database, the access control service will grant or deny the executing command. For 18 example, if an intruder steals the password of userA, he can log into the system and pretend to be userA. The access control system won’t Check the identity of the intruder again, and will treat him as userA. The intruder can access all resources available to the real userA. But the access control system guarantees that the intruder (pretending to be userA) cannot access the resources not available to userA. An authentication service in a Single system is much simpler than in a distributed system. A Single system is like a service room with only one door. Everyone comes in through the only door, so the person is verified when he enters the room. It is much easier to guarantee that person is not Changed once he enters. But in a distributed system, different services are located in different rooms. There is no one door for all of the rooms, so it iS hard to guarantee the person is the same when he uses different services. One easy way to solve the distributed authentication is to verify the user before he uses each service. The drawback of this solution is that it is difficult to maintain consistent identification information for each user in different services. If user identification information is Changed frequently, that will make the system even worse. On the other hand, it will be even more difficult to protect user identification information in a distributed system than in a single system. In a single system, the 19 user identification information is permanently stored inside the system, so the only way to get this information is to break in and steal it. But in a distributed system, that identification information needs to be transferred throughout the system. Sniffing from the network traffic to obtain the information is often much easier than breaking into a well-protected system. The discussion of authentication is beyond the scope of this paper. So in the following sections when we discuss access control, we assume that authentication has been correctly achieved, and the access control is only focused on what happens after authentication. 2.2.3 Auditing Access control is not a complete system security solution. It must work with auditing also. Auditing concerns a posteriori analysis of all the requests and activities of users in the system. Auditing is a deterrent because users may be discouraged from attempting violations if they know that all their activities are being tracked. The record generated by an auditing service can be used to analyze the users’ behavior in the system to reveal the attempted or actual violations. It also can be used to determine possible security holeS in the system. The essential of auditing is to ensure that the authorized users do not misuse their 20 privileges. The reader should remember that auditing still assumes that authentication is achieved. An analysis of auditing record can help to find out errors in the authentication service also. 21 Chapter 3 Access Control In this Chapter we will discuss access control in detail. Usually an access control system consists of policies and mechanisms. Policies are high-level guidelines concerned with how the security requirements are achieved; how an access is controlled; and how the control decision is determined. Mechanisms are low-level fundamental functions used to support access control and enforce the policies. It is desirable to develop access control mechanisms that can be used under different security requirements, so that the mechanisms can be used to enforce different access control policies. But policy is more case specific than mechanism. For example, the same operating system, such as Windows XP, provides the same access control mechanisms, such as setting file reading and writing permissions. When a same Windows XP is used in different environments (9.9. home vs. office), the access control policies could be dramatically different. At home the policy could be that “the parents can read the all kids’ files; kids have no permission to access parents’ documents; and one kid can access the other kid’s certain files.” But in the office the policies could be that “no one can access any file that is belongs to other person”. Fortunately the different policies could be enforced by the same access control mechanisms that are provided by the same Windows XP. Actually a policy is a configuration of access control mechanisms, which enforces certain access control requirements. Generally, it is hard to 22 compare different policies, because different policies are designed to accommodate different access control requirements. No policy suits all requirements. 3.1 Access Control Mechanisms In this section, the author will discuss four access control mechanisms, which are usually implemented in computer access control systems. The four basic mechanisms are: Access Matrix, Access Control Lists, Capability Lists and Authorization Relations. 3.1.1 The Access Matrix The goal of access control is to answer the question: “Who can perform what actions on which information?” To answer this question, we need to describe the access relationships, namely authorizations, among “who”, “what” and “which”. For this purpose, an access matrix is proposed [Harrison, Ruzzo et al.]. Table 3.1 is an example of access matrix. File 1 File 2 File 3 Mike O, R, W O R, E Helen W Joe R, E O, R, W, E Table 3. 1 an example of access matrix 23 These relationships are common in any UNIX system. Here 0 means “own”; R means “read”, W mean “write” or “modify"; and E means “execute”. From this table, we know that Mike is the owner of “file 1” and he can read and write “file 1”; Helen cannot access “file 1” at all; Joe can read and execute “file 1”. The access matrix represents various kinds of access preformed by the subjects (e.g. Mike, Helen and Joe) on the objects (e.g. “file 1”, “file 2” and “file 3”). In UNIX, the ownership of an object represents who has the privilege to decide the access permission of the object (file). Mike is the owner of “file 1”, so he can set access permissions of “file 1”. For example, Mike can grant read permission of “file 1” to Helen. The access matrix is a control mechanism. It is simple and straightforward to use. When the access control monitor captures an access request (including subject, object and action), the access control system Checks the access matrix. If the authorization is found in the matrix, the request is granted, otherwise it is denied. But how to create the matrix, and which authorizations should be presented in an access matrix are the problems that should be solved by access control policies. Different systems can have different access matrices. 24 A drawback of an access matrix is that when the number of subjects and objects become large, the access matrix will be enormous in Size, and most of its cells are likely to be empty. So in the real implementation, an access matrix is rarely used. Usually three alternatives are implemented instead of a matrix. They are Access Control Lists (ACLS), Capability Lists and Authorization Relations. 3.1 .2 Access Control Lists Access Control Lists (ACLS) are the vertical projections of an access matrix. Each object is associated with an access control list. Each element in the list represents a subject and all the permissions that the subject can perform on the object. Table 3.2 Shows the ACLS for the files in Table 3.1. File 1' [Mike|0, R,W [Joe| R, E j [Filez [MikelO [Helenjw ] [File3 lMike|R,E [Joel O, R, w,E J Table 3. 2 an example of ACLS From an object’s ACL, it is easy to determine what actions a subject can perform on the object. An AOL conveniently Shows all access settings with respect to the object, but it is difficult to know all the permissions that a subject has. 25 3.1.3 Capability Llsts Capability lists are the horizontal projections of an access matrix. Each subject is associated with a list (called capability list) that indicates which access is available to the subject to perform on an object. Table 3.3 Shows the capability lists for the users in Table 3.1. [Mike [File 1| 0, R,w [File 2| 0 [File 3| R, E 7 [Helen I File 2| 0 ] [Joe IFileI|R,E [FiIe3|o,R,w,E [ Table 3. 3 an example of Capability List Compared to ACLS, for each subject capability list make it easier to review the objects and the access settings associated with them. But it is difficult to determine all access associated with a particular object. ACLS and Capability Lists have their own advantages and disadvantages. If frequently creating and deleting objects, ACLS are much better than Capability Lists, since in an ACL it is very easy to grant or revoke access associated with an object. But when the user account is deleted (user leaves an organization or is 26 reassigned), Capability lists are more suitable. Modern systems typically use ACLS, because objects Change more frequently than users Change. 3.1 .4 Authorization Relations Different from ACLS and Capability Lists, Authorization Relation represents the Access Matrix, which does not favor one aspect of access over another. Table 3.4 is the Authorization Relations table of table 3.1. Subject Action Object Mike 0 File 1 Mike R File 1 Mike W File 1 Mike 0 File 2 Mike R File 3 Mike E File 3 Helen W File 2 Joe R File 1 Joe E File 1 Joe 0 File 3 Joe R File 3 Joe W File 3 Joe E File 3 Table 3. 4 an example of Authorization Relations Each row of the Authorization relations table directly represents an access authorization between a subject and an object. Each element in the list is a triple 27 of subject, action and object. If the table is sorted by objects, it is Similar to ACLS. And if the table is sorted by subjects, it can take the advantage of Capability Lists. The authorization relationship representation is typically used in relational database management systems. 3.2 Access Control Policies An access control subsystem includes low-level fundamental mechanisms and high-level policies. The Access Matrix is the low-level mechanism. For each access request, Simply checking the access matrix can determine whether the request is approved or not. Which access authorizations are recorded in the matrix should be answered by high-level policies. Four different access control policies will be discussed in the following sections: 1. Discretionary Access Control 2. Mandatory Access Control 3. Role-based Access Control 4. Layer-based Access Control Discretionary Access Control requirements “have been perceived as being technically correct for commercial and Civilian government security needs, as well 28 as for Single-level military systems.” Mandatory Access Control is “used for multi-level secure military systems, but their use in other applications is rare.” Role-based Access Control is more appropriate and central to the secure processing needs within industry and Civilian government than discretionary policies [Ferraiolo, Cugini et al.]. All three types of access control focus on the subject-object view of access control. Layer-based Access Control provides a new way to look at access control. According to the organization structure of an enterprise and the working mode, the access control system is divided into different layers; each layer can has its own access control policies (that could be any policies mentioned before). There is layer interface existing between the adjacent layers. Through this interface, policies in different layers are integrated. Layer-based Access Control is more flexible and extendable, and easy to take advantages from other policies and combine them together to build better policies. We implemented the Layer-based Access Control policies as a part of the security subsystem for a collaborative environment. All policies introduced here are not necessarily exclusive. Different policies can be combined together to provide a more suitable security system. 3.2.1 Discretionary Access Control In Discretionary Access Control (DAC) [Sandhu and Samarati], the decision of 29 whether a user can access information or not is based on the identity of the user. It is also based on authorization that specify, for each user (or a group of users) and each object in the system and the access modes the user is allowed. Every time a user wants to access an object, the access control system will Check the specified authorization. If the authorization exists, the user can access the object by the required access mode, then access is granted. A drawback of discretionary policies is that they do not really control the flow of information in a system. DAC does not impose any restriction on the usage of information once the user has received it, so a user who is able to read data can pass it to other users not authorized to read it without the knowledge of the owner. Basically two types of discretionary policies have been developed. One is Closed DAC, which means the default decision is denial of user’s access requests, and only if the authorization exists, is access granted. The other is opened, which means the default decision is to grant the user’s access requests, and only if the denial authorization exists, is access withheld. DAC policies are easily implemented by using an access matrix. 3.2.2 Mandatory Access Control 30 Discretionary Access Control cannot control the flow of information; Mandatory Access Control (MAC) [Bell and LaPadula] is designed to solve this problem. They control the access based on the Classification of subjects and objects in the system. Each user (subject) and each object in the system is assigned a security level. The security level associated with an object represents the sensitivity of the information contained in the object. The security level associated with a user (or call Clearance) reflects the user’s trustworthiness not to disclose sensitive information to users not cleared to see it. For example, in the military the Simplest security hierarchical level consists of TopSecret (TS), Secret (S), Confidential (C), and Unclassified (U), where TS is the highest level and U is the lowest level. (T S>S>C>U). To control the flow of information, there are two principles must be hold. Fiead down — the user can read information that has the same or lower security level as or than the Clearance of the user. Write up — the user can write information to object that has the same or higher security as or than the clearance of the user. 31 By using the those two principles, the information is forced to only flow from the lower security level to the higher security level or standing in the same level. One problem of the two principles is when the user does write up, it is possible to overwrite the existing higher-level information therefore destroy it. So many MAC systems practically do not allow information write up, but limit writing to the same level as the Clearance of the user. The systems forbid the user write up information, but allow the user send message to the higher-level users to let them know the new information is ready. So the MAC policies keep the information moving from the lower security level to the higher security level. Write up principle forbids the system writing any information to the lower level object, and at the same time forbid the user in higher level Clearance sending any kinds of messages to the lower level users, so that the inadvertent information leak can be prevented. The essence of MAC policies is that the information flow is one-directional in a lattice of security labels. Besides using to keep information security, mandatory policies can also be used to protect the integrity of information [Castano]. 3.2.3 Role-based Access Control 32 Lots of researches Show that DAC policies and MAC policies do not satisfy the needs of most commercial enterprises; DAC policies are too weak for effective control of information assets and MAC policies are too rigid to Change the access setting used in commercial enterprises. So during last decade, several Role-based Access Control (RBAC) policies were proposed. [Ferraiolo, Cugini et al.; Lupu, Milosevic et al.][securecomputing][CoulouriS, Dollimore et al.; Roeckle, Schimpf et al.] Role is the fundamental concept in the RBAC. Several different definitions were given. Ferraiolo [Ferraiolo, Cugini et al.] thought a role as “a set of transactions that a user or set of users can perform within the context of an organization.” Lupu [Lupu, Milosevic et al.] said, “A role is an “Identifier for a behavior, which may appear as a parameter in a template for a composite object, and which is associated with one of the component objects of the composite object.” And Sandhu [Sandhu and Samarati] defined a role as “a set of actions and responsibilities associated with a particular working activity.” To understand the concept of role, let us look at a hospital as an example. In the hospital, a doctor prescribes drugs to patients; a nurse assigned to the patients administers the prescribed drug to the patient at particular times; the patient is responding to treatment. In this example, the doctor, the nurse and the patient all 33 are roles. When we talk about them, none of them is directly referred to any individual person. And each of them just represents a set of action permissions. For example, a doctor represents the permission of writing a prescription. Any individual person can write a prescription, only if he adopts the doctor role. Roles are group oriented, which means that (i) a role represents a set of actions and responsibilities, and (ii) a role can be assigned to a group. Some reader could ask a question like that “in DAC policies or MAC policies, the manager also can grant permissions to a group of individuals instead of granting permissions to everyone of them individually, so why the concept of role is important?” Of course from the result, there is no difference between using role and granting permissions to a group. Both of them grant the same set of permissions to a group of individuals. But from the start point they are totally different. In DAC policies or MAC policies, the individuals are grouped together first, then grant permissions to the group. In RBAC policies, a role groups the permissions together first, then it is granted to a group of individuals. This is a very important viewpoint change, which starts a new way to think about the access control. 34 The role-based approach has several advantages. 0 Make access control more flexible The early access control systems grant access permissions of objects to the individual user directly. If an individual user is Changed, (such as leaving the company or being promoted, which are happened very frequently in a business or manufacturing environment), all the old access permissions granted to the user must be revoked, and new access permissions must be granted. This iS a cumbersome and time-consuming work. By using RBAC approach, this can be solved much easily. In a RBAC system, the access granting is separated into two phases. The first is to create a role and to grant access permissions to the role; the second is to assign the role to individual user. If the responsibility of a user is Changed, it is simply take back the role from the user and re-assign a new role to the user, then the problem is solved. Because of two-phase separation, the security designer can focus on the content of the policies without thinking about the user changing in the real world. Roles make the access control easier and the system more flexible. 35 0 Least privilege Least privilege is an important principle of security. It is secure that a user only gets the necessary permissions required by the particular task on which he wants to work. A role makes the implementation of least privilege easier. We can create a role with least privilege for the particular task, and assign it to an individual user. 80 we can minimize the danger of damage due to inadvertent errors or by intruders masquerading as legitimate users. 0 Separation of duties Separation of duties means that no individual user should have enough permission to let himself misuse the permissions in the system. For example, in a bank, it is not allowed that a person authorizes a loan that is applied by himself. In summary, the RBAC policies contain four basic elements: Users, Roles, Permissions and two types of role assignment relations: User/Role, and Role/Permission. [Ferraiolo, Cugini et al.] The RBAC policies can be represented as: 36 AC(s,a,o) = R(s, r) + AC'(r,a,o) Where AC() is the function of access control, R() is the assigning relationship between S (user) and r (role), AC'() presents the relationship among r, a (action/permission), and 0 (object). 3.2.4 Layer-based Access Control Compare with MAC and DAC, RBAC provides more flexibilities, and easier management. But in an manufacturing environment, that is not enough. For example, RBAC policies do not capture the organization structure of the manufacturing enterprise, but also they did not represent the objects into a hierarchical structure. Roles and objects still directly map to each other by using access matrix. To solve this kind limitation of RBAC policies, we propose Layer-based Access Control (LBAC) model. Our LBAC inherited the concept role, captured the enterprise organization structure, and created hierarchical structure for objects. LBAC policies could adopt other kind policies (MAC, DAC and RBAC) easily. Inside of an enterprise, usually it has several different units that are organized into a hierarchical structure. For example: 37 [ CompanyA] [ DivislionA ] [ Divisions] [ DivislionC ] [DepartlmentA] [ DepaT'tTrlentB] [DepartmentC] [ Tag... ] [ Tealmz ] [ merrfben J [ meriberz ] Figure 3. 1 the organization structure of companyA As figure 3.1 Shows, a middle size company usually contains one or more divisions. A division contains several departments. And each department consists of several teams. And team includes one or more members. According to the hierarchical structure, the company can be divided into different levels. In this example, the companyA is in the highest level; divisions are the next level; and the members are in the lowest level among the hierarchical structure. From the security view, the lower level units (9.9. Team1 and Team2) inside a higher level unit (DepartmentA) are hidden by the higher level, which means that a unit that collaborates with departmentA (such as departmentB) only knows departmentA, and does not know that departmentA has two teams inside. In a system with RBAC, this kind organization structure is not captured. 38 Unlike other policies treating the objects individually, LBAC also groups all objects into a hierarchical structure, and uses the hierarchical structure to represent the objects. In a manufacturing environment, the all objects are not independent. They are related with each other by manufacturing processes. Then we use a example to Show how objects a related together by a process. For example, companyA wants to design a new bicycle. The whole procedure of designing the new bicycle is called the process of bicycle design. So we can name the entire process as “bicycle design”. In the manufacturing environment, when a process is complicated, usually the process is divided into several smaller parts. And each small part can also be divided. This kind division is recursively continued until each small pieces of the whole process can be handled easily. Following this idea, the “bicycle design” can be divided into “body design” and “wheel design”. And the “body design” consists of “handle bar design”, “seat design” and “frame design”. Suppose these small pieces of the entire “bicycle design” process, “handle bar design”, “seat design”, “frame design” and “wheel design”, can be handled easily. The process division is terminated. So we get a hierarchical tree structure of the process, which is shown in figure 3.2. Now let’s see how the process-related objects are grouped into this tree structure. Actually only the leaf nodes related to the really objects, such as the “handle bar 39 design” relates material, CAD system and other objects needed to finish “handle bar design”. It is Similar that “seat design”, “frame design” and “wheel design” are individually associated with certain objects. So each of the leaf node can be used to represent the set of objects that are needed to complete the piece of process represented by the leaf node. For example, the “handle bar design” delegates all objects used for designing a handle bar. Bicycle design ] [ Body design ] CWheereSign E I [Handle bg'design] [ Frameldesign ] Seat design [ Matgrial ] [ CAD sOftware ] [ ] Figure 3. 2 the hierarchical structure of project “bicycle design” In the tree, a higher level node (9.9. body design) can be used to represent all objects related to the subtree. “Body design” represents the union set of objects represented by “handle bar design”, “seat design” and “Frame design”. So that all process related objects are grouped into a tree structure. These two hierarchical structures are defined independently. In an enterprise, the organization structure defines the structure of subjects. The division of a process defines the structure of objects. When the process is carried out, these two 40 independent structures are connected together, which means there are certain relationships between those two structures. Suppose the entire process “bicycle design” is carried out by departmentA. So the all objects represented by “bicycle design” are related to departmentA. Since the “bicycle design” can be decomposed into two parts: “body design” and “wheel design”, which are handled by team1 and team2 individually. Then team1 and all objects related to “body design” are related to each other, and it is Similar to team2 and objects associated with “wheel design”. Inside of team1, memberI and member2 take care of “handle bar design” and “seat design” separately. All these relationships are common in the manufacturing environment. For the “bicycle design” example, we found that all those mappings are not in the same level. According to the structure of objects, the mappings also have a hierarchical structure. For example, departmentA associates with all objects related to “bicycle design”, and the team1 only associates the objects related to “body design”, which is a subset of the objects related to “bicycle design”. The mapping is shown in Figure 3.3. From this figure, we know that the subject-object mapping can be divided into different layers according to the scope of the objects. The “body design” is a subset of “bicycle design”, so the 41 of the objects. The “body design” is a subset of “bicycle design”, so the “team1”-“body design” mapping is in the lower layer inside of the “departmentA”-“bicycle design” mapping. It is similar that the “member1”-“handle bar design” mapping layer is inside “team1”-“body design” layer. / A... \ departmentA Bicycle design / layer1 @ \ team1 Body design / Iayer0 Ej \ Handle bar member1 k\ k design / / FigureS. 3 the layer mapping between organization and project By using this layer structure, the subjects and objects are limited into the certain layer. So the entire access control is divided into two parts: access control inside a layer and the access control between the adjacent layers. Layer-based access control (LBAC) separates the accesses into two different types, one is the access requests come from the subjects inside the layer, and the 42 separation, we can use different access control in different layers and between different layers, which make the security system more flexible. AS shown in Figure 3.3, the layerO is the lowest one in the layer structure. In figure 3.4 layer0 contains members, objects and the access control between them. Within layerO the access control can be enforced by any policy we mentioned before. Because layer0 hides all detail (subjects, objects and access control policies) from outside of the layer. So the system must provide an interface to let information can be exchanged across the boundary between the layers. The interface contains two components: contract and report. A contract is used to exchange the access control information between the layers. A report lets inside members access the outside objects, and also let the outside subjects can access the inside objects. Which objects are exported through the report and which objects can be import from the report are controlled by the access control policies within layerO. Figure 3.5 shows the access control within the higher level layer (here is layer1). Within layer1 the access control can be totally different from the one used in layero. In this layer the access control handles two different cases. one is which object information should be exchanged between different reports. For example, the object information exchanges between the two layerO reports; and the 43 information between the IayerO report and layer1 report. The other is to control the subjects in layer1 to access the reports of Iayer0 and layer1. The contracts of layer0 and layer1 still are used to exchange the access control information between the layers. The exchange access control information means that, for example, when the access control policies of layer1 are created, the contracts of layerO and layer1 should be considered. Contract I Report r layerO \ AC members Objectsj Figure 3. 4 access control in the lowest layer The layer-based access control mode can be easily extended from layer1 to layerN. Except the lowest layer (layerO), the access control model used in other layers is the same. From figure 3.5, we know the policies used in different layer are separated, so our layer-based access control mode can easily adopt the most suitable access control mode in different layer. Those make the whole access control system more extendable and flexible. 44 I I r Contract I I Report I / \ayefl \ ‘ AC - [ContractI I Report I Eontractl I Report I layer0 layerO e «flfi 9 «ate \Qembers Obiecy \Members Objects/ Figure 3. 5 Access Control between different layers LBAC Model vs. Object-Oriented Approach The design of Layer-based Access Control has borrowed some ideas from the object-oriented approach. Object-orientation iS proved as a successful approach for system analyzing and designing [Capretz]. Some Characters of object, which plays the central role in the object-oriented approach, are adopted by the LBAC. Those Characters include abstract, encapsulation, messages and dynamic binding [Rentsch; Thomas and Sandhu]. 45 Object-orientation is effective to deal with system complexity by using abstract concepts. Abstract helps designers isolating certain aspects that are important for an understanding of the system, and also suppressing those aspects that are irrelevant, which makes whole system easy to be understood. Forming abstracts of a system in the terms of Classes and objects iS one of the fundamental tenets of the object-oriented paradigm. When designing a LBAC policy, we use abstract to create subject and object hierarchical structure. Such as the team is an abstract of all subjects of in team1, and “bicycle design” is used to represent all objects related to the entire process. In an object-oriented programming language (such as java, C++), “Encapsulation is the concept that an object should totally separate its interface from its implementation. All the data and implementation code for an object should be entirely hidden behind its interface.” [Lhotka] Creating an interface is the way to implement encapsulation. The object interface defines the public data and methods that can be accessed from the outside of the object, and the private data and methods are hidden inside the object. This Character is very useful to design an access control system. In the Layer-based Access Control system, the layer encapsulates subjects, objects and access control policies inside the layer. From outside of the layer, all these information is hidden. A layer interface iS created to exchange information (9.9. contract and report). 46 In the object-oriented approach, all objects communicate using the same mechanism of message passing. In Layer-based Access Control, message is used to set contract and read and write content of a report. LBAC vs. MAC Layer-based Access Control (LBAC) and Mandatory Access Control (MAC) all Classify subjects and objects into different categories. But the basic way to Classify them is different. The differences are: 1. MAC Classify subjects and objects according to the sensitive levels of the subjects and objects. LBAC classify subjects and object into levels based on the information hierarchical structure. 2. MAC guarantees the direction of information flow, but it is too strict for the enterprise environment. LBAC does not force the direction of information flow. But by setting additional rules, LBAC can control the information flow also. 47 3.3 Related Research Role-based Access Control model has increased the flexibility of the access control system, but it still has some limitations, such as it does not capture the organization structure; it does not capture relationships among objects; and it is not designed for distributed collaborative environment. To overcome those shortages, researchers had extended the role-based access control model in several directions. Task-based Authorization Controls Different from the Role-based Access Control model, Task-based Authorization Controls (T BAC) [Thomas] is a task oriented model for access control and authorization. The core of TBAC is the active security model that is well suited for distributed computing and information processing activities with multiple points of access, control, and decision making. TBAC focuses on security modeling and enforcement from the application and enterpriser perspective rather than from a system-centric subject-object view. In the TBAC paradigm, permissions are Checked-in and Checked-out in a just-in-time fashion based on activities or tasks, but in the subject-object paradigm, to allow 48 an access request or not is based on whether a subject has the required permissions for the action, and it does not care about the context of the task. The SALSA Security Architecture The SALSA Security Architecture [Kang, Park et al.] handles access control within and among organizations. These organizations are connected together by inter-organizational workflow. There are two kinds of access control modules in the overall security architecture. 1. An organization-specific access control module (OACM) that is controlled by each organization and enforces a security policy that is set by each organization. 2. A task-specific access control module (T ACM) that is controlled by each workflow and enforces task-specific security policy. Only a person with intimate knowledge of the workflow can set the security policy of each task because, in general, a task-specific security policy depends on the semantics of the workflow. 49 The security design in the SALSA Security Architecture is different from the design in the Layer-based access control model. In the SALSA Security Architecture the access permissions to a task are decided at the design-time of the workflow. So during the running time, the permission settings cannot be Changed. On the contrary, the permissions in the Layer-based access control model are set during the running time, and can be dynamic Changed when the process is executing. Another difference is that the access control in SALSA Security Architecture focuses on controlling the access initiate by a task to information (data). The Layer-Based Access Control deals with the access between system users and tasks running in the system. Domain-based Access Control Domain-based Access Control (DBAC) [Argus-Systems] is based on the concept of access domain (AD). BDAC labels both subjects and objects, so it can be used to impose a security policy on users and programs, and can be used to create compartments or partitions within the system. DBAC does not provide information flow protection, but it does provide separate access rights for different access 50 modes, and permits users and processes to operate outside the control of the DBAC entirely. In a DBAC system, a subject (here referring to a process) has two execution modes. One is the common execution mode in which the process does not recognize any restrictions imposed by ADS. The other is “AD aware mode”. When a process is created in this mode, the execution of the process is restricted by ADS. And the process cannot Shift out of the AD aware mode. DBAC is more intuitive and easier to manage comparing with RBAC. it suits the simple environment, such as small businesses, home users and enterprise-wide deployment. But to control access in a complicated collaborate environment is beyond its capability. After we see several different access control models, in next Chapter, we will introduce how the Layer-based Access Control policies are actually enforced in MIDAS. 51 Chapter 4 Manufacturing Infrastructure and Design Automation System (MIDAS) In Chapter 2 and Chapter 3, we briefly introduced the theories and techniques that are used in Virtual Enterprise. In this Chapter we will discuss in detail about the security design of MIDAS, in which the Layer-based Access Control policies were implemented. To understand security issues, MIDAS Should be introduced first. Basically MIDAS is a process management system, which deals with how manufacturing processes are represented, how the processes are created, how execution of processes is controlled, and how different processes are coordinated. 4.1 Formal process grammar Process is a core concept of MIDAS, so we start to introduce the basic process-related concepts briefly before we discuss the structure of MIDAS. These concepts introduced here could help readers understand this system. These concepts include process, process flow graphs, process grammar and so on. Process: 52 In the manufacturing environment, a process is defined as “a series of operations performed in the making or treatment of a product.” [dictionary] There are several different ways to represent a process [Wang] [Riddle] [Erdmann and Wortmann]. MIDAS uses process flow graphs to represent processes. Process flow graph: A process flow graph is a flowchart that is used to represent a process in accord with process grammar. The flowchart defines the objects and the relationships between objects in a process. Process grammar: Process grammar [Baldwin and Chung] is a set of rules, which are used to define and document processes. By using this grammar a process can be defined and represented easily, and without ambiguity. Process grammar has four basic elements: Tasks (Logical tasks and Atomic tasks), Specifications, Selectors and Databases. Tasks: A Task represents an activity. According to the Character of tasks, tasks are 53 Classified into two-level categories: Atomic tasks and Logical tasks. Atomic tasks are the low-level tasks that represent the un-decomposed activities or indivisible units of activities (such as a transaction in a database system. each unit transaction is a whole transaction that cannot be interrupted when it is started. There are only two results of the transaction: one is completed, the other is failed. No internal statuses are visible for the outside of the transaction.) Logical tasks are the high-level tasks that represent abstract activities that can be divided into several different smaller tasks, and each smaller task could be a logical task or an atomic task. In other words, the logical task is a combination of logical tasks and/or atomic tasks. Specifications: Specifications are data artifacts that are generated and consumed by Tasks/Selectors. Note that in accord with the process grammar, a specification only can be generated by one task, can be consumed by multiple tasks/selectors. Selectors: 54 A selector is a special atomic task, which takes at least one database (a special specification) as an input. The selector queries the database, keeps the queried data from the database, and each time return one datum from the queried data. Databases: A database is a Special specification that provides information to Selectors, therefore. Databases are provided by the process designer, and they are not generated by any tasks in the process. In the flowchart, the elements are defined as following: specification Figure 4. 1 basic objects in MIDAS Here is an example of process flowchart that is created in accord with process 55 grammar. Requirement MaterialDatal RoughGeometry esignModelDB MaterialDataZ FinalModel Product Figure 4. 2 an example process flowchart Until now the basic elements are Clearly defined, and then we need to define relationships among these elements. These relationships include generation, consumption, sequence and concurrent. Generation: Generation is the relationship between tasks/selectors and specifications. Specifications are generated by tasks/selectors. One specification only can 56 be generated by one task/selector; and one task/selector can generate multiple specifications. In the flowchart, generation is represented by a line with an arrow. The line starts from a task/selector and points to a specification. For example, in figure *, specification “MaterialDataI” is generated by the logical task “StatiCAnalySis”. Consumption: Consumption is the relationship between a specification/database and a task/selector. Tasks/selectors consume the information that is stored in the specifications/databases. Each task has one or more specifications as inputs. Each selector has one or more specifications and one or more databases as inputs. In the flowchart, consumption iS represented by a line with an arrow. The line starts from a specification/database and the arrow points to a task/selector. In the figure, the selector “SelectModel” consumes the specification “RoughGeometry” and the database “DesignModelDB”. Generation and consumption essentially represent the flow of information inside a 57 process. The information flow is starting from the inputs of the entire process (e.g. specification “Requirement" and database “DesignModelDB”), and information goes through the tasks/selectors (e.g. “StaticAnalysis”, “BriefCac”, “DynamicAnalySis”, “SelectModel”, and “Manufacture”) and finally ends at the outputs of the whole process (e.g. “Producf’). Sequence: Sequence represents the relationship between tasks/selectors. Assume there are two tasks task_A and task_B. If all or parts of specifications, which are consumed by task_B, are directly or indirectly generated by task_A. Task_A and task_B are sequence, and task_A must complete before task_B starts. And task_B depends on task_A. For example, in the figure, the task “StaticAnalysiS” and the task “DynamiCAnalysis” are sequence. Concurrent: Concurrent represents another relationship between tasks/selectors. If task_A and task_B are not sequence, they are concurrent, which means they can be performed independently and concurrently. And there is no dependence between task_A and task_B. such as task “DynamicAnalysis” and task “SelectModel”. 58 The logical task is an abstract task, and it can be decomposed. In the design and manufacturing environment, for a logical task, usually more than one ways exist to decompose it. So more than one productions associate with this logical task. Each production represents one way to decompose the logical task. All decompositions are alternatives to the logical task. For example: there are two different ways (e.g. production 1 and production 2) to decompose the logical task “DynamicAnalySiS”, which iS shown in figure 4.3. Each production just is a special process. The production is also defined in a process flow graph. The process grammar is also used to define a production. 4 a logical task and related productions Production 1 Production 2 Logical Task MatefialDatal MaterialDatal MaterialDB MaterialDatal riefAnalysi SelectMaterial @ E:> tempData tempData MaterialDataZ @@ @@ MaterialDataZ MaterialDataZ Figure 4. 3 a logical task and related productions 59 In the manufacturing environment, a logical task represents an abstract activity. An atomic task/selector refers to a concrete and unbroken activity, and usually it relates to external tools. In the view of MIDAS, an external tool is an unbroken activity. MIDAS provides inputs to the external tool and invokes it, then waits till the external tool finishing its work and sends the result back to MIDAS. The execution of the external tool is not controlled by MIDAS, so that to MIDAS the external tool is an unbroken activity. Specification and database relate to the information data used in the manufacturing process. 4.2 Collaboration In MIDAS Basically there are two main parts in MIDAS. One is a process management engine that deals with how a process is generated, controlled and executed. The other is a collaborative environment, which supports fundamental functions of collaboration and security. For the process management engine part, please read [Qin] for detail. In this paper we will discuss the collaborative environment only. Before we start to talk about the collaborative environment, it is necessary to briefly introduce how the engine works or what does “execute process” mean? 60 When a process is defined by using process grammar, it is a visible flowchart (for example, a simple process is Shown in figure 4.2). All specifications and databases in the flowchart store the process information, when the process is executed the specifications will be consumed or generated by tasks/selectors, the databases will be queried by selectors. The tasks/selectors represent all activities that need to be performed in the process. To execute a process means to perform all activities (e.g. logical tasks, atomic task and selectors), which are defined in the process. The activities consume and generate data in accord with the order defined in the process flowchart. When a process is executed, tasks/selectors are applied. There are two different types of “apply" in MIDAS. First type “apply" is performed on a logical task. A logical task is an abstract activity, it can be performed in different ways, and each way is represented as a production. A logical task could relate to multiple productions. To apply a logical task means selecting a production to replace the logical task in the original flowchart. For example, if the logical task “DynamicAnalysiS” is applied by “production 1”, then the process flowchart is Changed to the one Shown in figure 4.4. 61 The second type “apply" is performed on an atomic task or a selector. To apply an atomic task or a selector means to invoke an external tool. The external tool takes the inputs of the atomic task/selector, generates results, and then sends the results back to MIDAS. For example, to apply the atomic task “BriefAnalysis”, MIDAS will call an external program to take the data that is contained by specification “MaterialData1”, after running the program, MIDAS receives the results generated by the external program, and stores the results into the specification “tempData”, then the procedures of applying an atomic task is done. To apply a selector is the same as to apply an atomic task. 62 Requirement RoughGeometry Desi gnModelDE MaterialDatal i @fAnaD T tempData SelectModel i I DetailAnalysis FinalMOdel MaterialDataZ Manufacture O Product Figure 4. 4 the process flowchart after applying a logical task The difference between applying a logical task and applying an atomic task/selector is: 1) To apply logical task, the user can see how the logical task is applied, which means the user know every step that is taken to complete the logical task; 63 2) To apply an atomic task/selector is like to “pushing a button” on a machine, the machine takes the input and generates the output, the user does not know any detail about how the machine works. In a process flowchart, if we continue apply the logical tasks, finally we will get a process flowchart that only contains atomic tasks/selectors and specification / database. The final process flowchart is called process configuration [Keyes]. 4.3 The System Structure of MIDAS YP server Tool servers AC ”K Toolservers Ma' servers A 4 Main serv ”\\ Cockpit Cockpit Cockpit fl Cockpit Figure 4. 5 The distributed structure of MIDAS Figure 4.5 shows the structure of MIDAS. The basic components of MIDAS are Main servers, Tool servers, Access Control (AC) servers, Yellow Page (YP) server and cockpits. Main servers: They are the process execution engines of MIDAS, it holds the process management that includes creating, managing and maintaining production libraries and external tool libraries, executing processes, invoking external tools and stores the results. Tool servers: They are working with Main servers to invoke the external tools, actually when the MIDAS engine want to invoke an external tool, the Main server sends an invoking request to a Tool server, then the Tool server really invokes an external tool according to the request sent by the Main server. Any system can be treated as an external tool, such as the existing CAD/CAM systems, 2D/3D Simulation systems and even human beings. AC server: It is the central part of access control subsystem. The main functions of AC (Access Control) server are user management, group management, 65 authentication, access request monitoring, granting and denying, policy maintenance etc. YP server: An YP (Yellow Page) server is the information center among different MIDAS domains (Domain will be introduced later). It maintains a list that contains information about current running servers in all domains. Each element in the list contains information of one server, which includes domain, server ID, server IP, and server Type (e.g. main server, tool server or ac server). When a server is started, it will register itself to the YP server. YP server Checks all registered server frequently (such as every five minutes). If any server in the list is not alive, YP server will delete the server from the list. By Checking this list one server can find the IP and ID of other server to which it want to connect. (For example, when a main server wants to talk with a tool server, the main server could retrieve the IP and ID of the tool server from the YP server.) Cockpit: This is a Client side program of MIDAS. Users use cockpits to interact with MIDAS. By using cockpit, the users can create, execute process, and manage task libraries and tool libraries. Administrator can manage user, 66 group, and member in each group. Group manager can maintain hiS own group. Servers and cockpits are grouped into domain, which will be introduced in detail later. As showed in figure 4.5, the YP server is the only server across different domains. The VP server is an information center for different domains. Through the YP server the servers in different domains can talk with each other. Each domain has only one AC server. The AC server handles all access stuffs within one domain. The AC servers in different domains talk with each other to deal with the access control among domains. Each domain has several main servers, tool servers and cockpits, which provide an environment to manage manufacturing processes [Keyes; Qin]. 67 Chapter 5 Security Implementation In MIDAS To develop a security subsystem for MIDAS, the first step is to find out what security means here, namely what are the security requirements of MIDAS. MIDAS is a collaborative environment to support process management, so at least two functions must be supported in order to provide security. The first function is the subsystem must guarantee that only the legal user can use the system, which is the authentication part of the subsystem. The second function is how the subsystem supports access control within different collaborative activities. This is the main part of the subsystem. 5.1 Authentication In MIDAS Authentication is an essential part of the security subsystem, all remain parts are built on the top of it. Every security decision in the later part of the system assumes authentication works correctly. For the authentication part we took the simplest structure to design and implement it, since our focus is to develop an access control system for the collaborative environment. As most systems did (such as UNIX systems), MIDAS 68 uses username and password to identify each user. The user is authenticated by Access Control (AC) server (figure 5.1). The person, who wants to use the system, must log in the system by providing his/her username and password. Then the login request is sent from cockpit to AC server. The AC server Checks the user information database, if the user provides the correct username and password, then the login is success, otherwise the login is failed. login request __ .-~ Grant/ deny AC server Cockpit Figure 5. 1 Authentication in MIDAS The main part of the authentication is the user info database. In the implementation level, we use XML file to build the database. There are two reasons to choose XML. First, XML file is a good way to represent and store data [W30; Routledge, Bird et al.]. XML supports structured data, and it is easy to read, modify and debug. The data structure represented in XML is extendable, which means that if some new information is needed, it can be easily added into the data structure without 69 affecting the existing program. Second, our system is a prototype system. It is not necessary to support huge number of users, and the information of each user is simple. The entire size of user information data is small. So it is not necessary to use other existing database system to implement this part. Since XML becomes a stand way to exchange data between database systems, in the future, if the database system is used, it can be easily adopted by our system. The following iS a piece of the user info database: downer» dIoglcaI> downer» datoml» downer» 84 dpennisslonLlsb List 5. 2 a permission list After the process is initialized, the user can start to apply logical tasks, atomic tasks/selectors. When atomic tasks/selectors are applied, no new objects are created. When a logical task is applied, according to the production the user chose, new objects are created and added into the “permission list" (list 5.2). If the logical task “DynamiCAnalySis” is applied by production 1 (figue 4.3), the following new objects are created: atomic tasks: BriefAnalysis, DetailAnalySis, Specification: tempData. Those elements in list 5.3 are added into list 5.2. downer» datoml» 85 downer» datoml» downer» ddet» List 5. 3 a list of new objects after applying a logical task In the single user execution mode, the access control concern is how to control other users to access the objects related to the process. Since no collaboration exists in this mode, the accesses request from other users are limited to “view” only, which means in the single user execution model, other users only can see what is happening on the process. Based on the secure requirement, we decide to choose the DAC policies for this 86 mode. The detail of the policy as following: 1. The user who creates the objects is the owner of those objects. (see list 5.2 and list 5.3) 2. The owner can grant any access permissions to himself, such as giving himself “execute” permission of logical task “StaticAnalysis”, “execute” permission of selector “SelectModel”, and “view” permission of “MaterialData1”. To make user convenience, we give the owner all access permissions of each object by default. The owner can tailor the permissions in the future. For example, the logical task “StaticAnalySiS” entry is changed to: 87 dexecutor» downer» wer m m rName='kim"/> d viewer» dlob> d viewer» assigner assignerName='manager'/> 96 djob> dprolect> dgroup> dassignedJobLIsb List 5. 6 an assigned job list In this example, the “Alpha” is the group that is working on project (we will define it later) “ProductDesign”. The flowchart of the project is Shown in figure 4.2. From this assigned job list, we know that the manager of group “Alpha” assigned logical task “DynamicAnalysis” to the member “analyst” as a job. By default the job name is the name of the logical task — “DynamicAnalysiS”. This list is not used for access control purpose only, so it also contains other information that is used for process execution. Such as “library", “template", “state” and so on. The access control related information is “assigner", “assignee”, “task” and “assignContract”. . “Assigner” records the role who assigned this job. The assigner can be the manager or any member in the group. Here the assigner is “manager". 97 . “Assignee” records the role who received the job. The assignee can be any one in the group. “Analyst” is the assignee in this example. . “Task” records which logical task in the original process is assigned to other member as a job assignment. Here is the logical task “DynamicAnalysis”. . The purpose of “assignContract” will be explained later. For this case, it is not necessary. Here are the steps of access control and what happened in each step. 1. The assigner Chooses a logical task (e.g. “DynamicAnalySis”). The system will Check the assigner has the permission to assign the task or not. (for example, to check the assigner part of the logical task “DynamicAnalysiS” in the “permission list”) Note: before the assigner picks up the logical task, the logical task already exists in the “permission list”. 2. Assigner Chooses a member (assignee) and assigns the job to him. In this step, there are some works need to be done, such as creating job template, preparing library, deciding job start, end, estimated time. All those 98 information are needed for assignee to work on the job. Then the system updates the “assigned job list” and records all information related the job. (List 5.6) 3. The assignee gets job assignment information from the “assigned job list”. After he starts the job assignment, a job object “DynamiCAnalysis” is created into the “permission list”. And other new objects are added into the “permission list” as we described in Single user/role execution mode. And the assignee can set the ACL of the job object and other objects that belongs to the job. Now let uS see how access control works for the first case of job assigning. Suppose the member “guest” iS granted the view permission of the logical task “DynamicAnalySis” from the manager. After “guest” sends a request, figure 5.3 shows how the access control system Checks the permissions. 99 @ccess RequeQ Logical task ant . ACL Find Job 4 Job ACL deny deny grant den ant Figure 5. 3 Check permission If “guest” want to view the logical task “DynamiCAnalysis”, the access control subsystem will Check the ACL of logical task “DynamicAnalySis” first. If the request is granted, the system needs to find out which job is related to the task. Because the task was assigned to the member “analyst", the next level flowchart detail of the logical task is not controlled by “manager", and it is belongs to “analyst”. Then the access control subsystem Checks the ACL of job (by default, the job and the logical task have the same name: “DynamicAnalysis”, but there are totally different objects in the “permission list”, and both of them may have totally different ACLS). If the “guest” is on ACL of the job, the view request is granted, otherwise it is denied. If the view request is allowed, “guest" can see the next level detail of the logical task. If he wants to view more detail of the logical task, the further “vievv” request is granted or denied are totally depends on the access 100 control decision of “analyst”. The second case of job assigning is that the assigner wants to control the access of objects that are related to the assigned job, namely the job is not totally controlled by the assignee, and the assigner also can put some kind control of the objects within the job. By adding new features to the solution for first case, we can satisfy the new requirement. To allow the assigner to control the access, we create a new type of file, called contract, to handle it. In list 5.6 the element “assignContract” records where this contract information is stored. The contract defined the access rules that the assignee may/must follow. List 5.7 shows an example of the contract. 101 < viewer name='qualityTester'/> d viewer» dexecutor» assigner» dasslgner» dpoiicy> List 5. 7 a contract From this example, the reader can find out that the contract actually is an ACL of the entire job. The contract only defines the general rule to control the accesses of the whole job. There iS no rule to a Specific object that will be created during the job execution, because when job is assigned, the assigner cannot know what objects will be created. The attribute “override” of the element “policy" is important for this contract. If the override is set to “yes”, which means the contract can be overrode by the assignee. The contract just is control suggestion, and it is not necessary to be followed. If all rules in the contract are empty, such as the executor element in list 102 5.7, it means the assigner abandons the control of the job. So that the second case of job assigning becomes to the first case of job assigning and everything go back to the one we discussed before. If the override is set to “no”, the contract must be followed, and the assignee cannot modify the rule that defined in the contract, but he can add some new rule to it. If the contract in list 5.7 is used when the “analyst” starts the job “DynamicAnalysiS”, the following entries will be added into the permission list. Note that the entries with underline are added according to the contract of the job. downer» < viewer» dviewer» dlob> 103 downer» downer» 104 < viewer memberName='g ual'flTester'b dexecutor» datoml» d viewer» ddat» List 5. 8 permission list with info of a contract When an access request is received, the subsystem still follows the same way 105 (figure 5.3) to check the permission settings and decides to allow the access or deny it. When the assignee want to assign part of his job (one or more logical tasks in his job) to other member, if the contract cannot be overrode, the contract must be inherited when he generates the contract of the new job. The access control associating with job assigning belongs to layer1 of LBAC model. And the job assign contract is the contract component in the interface between layer0 and layer1. Because we assume that all members in the same group are trustable, the report component in the interface between layer0 and layer1 is simply contains all objects listed in the “permission list”. So no special report is created. Besides the job assigning, there is another kind collaboration within the group. It is that the owner of an object (logical task or atomic task/selector) can give other member privilege to perform some actions (execute or assign) on the object on behalf of the owner himself. Comparing with job assigning, the differences are: c On the owner’s behalf is much simpler than job assigning. No job template, job contract and other job-related information need to be created. 106 o On the owner’s behalf, the result of task execution still belongs to the owner, and the result is available to the owner immediately. In the job assigning, the result belongs to the assignee. Only after the assignee returns the result, the result becomes visible to the assigner. . Based on the contract, the job assignee can control the objects inside the job. But when a member on the behalf of the owner, the member cannot set the AOL of the new created objects. That means the accesses of the new objects are still controlled by the owner and not the one who executes the task. When the owner grants a privilege “execute” and/or “assign” (for logical task only) to another member, the member automatically get “view” privilege of the higher-level object, the “view" privilege is spread up until the highest-level object (which usually is the job object). On the owner’s behalf, when a logical task is executed, according to the selected production, new objects are created. Here is the policy of setting ACLS of these objects: 107 . The owner of the logical task owns the new objects; 0 If the logical task is executed, the executor will continue be the executor and viewer of the new logical tasks end/or atomic tasks/selectors; the executor will be the viewer of new specifications/databases. (Here executor refers to the member who performs the “execute” action, and viewer is the member who can perform the “view" action on the object). o If the logical task is assigned, the member who performed the assigning decides the assign contract. But the result of the job assignment is returned to the owner of the logical task, not the member who performed the “assign” action. The access control policies used in “on the behalf of owner" belongs to layerO in the LBAC model. Because in the viewpoint of access control, there is no difference between granting “view" permission to other members and granting “execute” and “assign” permission to other members. 2. Task assigning between groups In last section we talked about the collaboration within the group. In this section, 108 we will discuss the collaboration between groups and the related access control policies. In MIDAS only one collaborative exists type amongst groups - project assigning. The definition of project assigning is similar to job assigning amongst members within a group. Project assigning means that a logical task is assigned from one group to another group. A project iS an assignment to a group. Here an assigner group refers to the group that gives the project assignment, and an assignee group is the group that receives the project assignment. After the assignee group completes the project, the project result must be returned to the assigner group. The result contains two parts: the process configuration flowchart and the final data generated by the project. Besides the final result, in accord with the security contract between the groups, the assigner group also can request the progress report of the project from the assignee group. The progress report should contain the current flowchart of the project and the data that are generated during the execution of the project. Different from the assumption used within a group, here we assume the groups are not trustworthy. So project-related information is divided into two parts: one for assigner group, and the other for assignee group. 109 Similar to the assigned job list, there are two lists are created for project assigning: received project list (list 5.9) that records the information of projects received by the group, and given project list (list 5.10) that records the information of projects given by the group. assigner assignerName=“Bete"/> dprolect> dgroup> dreceivedProlectLisb List 5. 9 an example of received project list 110 dprolecb dgroup> dgivenProlectLisb List 5. 10 an example of given project list Received project list (List 5.9) is stored in the AC server of group “Alpha”. From this list we know received project name, template, library, assignContract, assigner and state. Project, assignContract and assigner are related to access control. Given project list (List 5.10) is stored in the AC server of group “Bate”. In the given project list, project, task, assignee and assignContract are related to access control. 111 Since the untrustworthy between groups, the policies for project assigning are divided into two parts also: one is for the assigner group; another is for the assignee group. . The policies for the assigner group 1. Only the assigner group manager can assign a logical task to other group as a project assignment. The member cannot give part of his work to other group directly. If a member wants to do it, he must give the logical task to his group manager as a job. Then the manager can give the logical task in the job to other group as project assignments. 2. When a project assignment is given, the assigner group must prepare a project template, libraries and productions. This information should be sent to the assignee group. At the same time an assigning contract is created (list 5.9 “ProductDesign_report.policy”). This contract is different with the one used in the job assigning. This contract defines what kind information needs to be reported from the assignee group to the assigner group. This contract is a high-level description. 112 3. When a project is assigned, a local access policy is created (list 5.10 “ProductDesign_local.policy"). The access policy defines who can access the objects in the progress report and final result. This policy only effects within the assigner group. The manager is the owner of the objects in the report and final result. Based on the real situation, only “view” action can be performed on the objects in the report and final result. 4. Only the manager can accept the progress report and final result of a project assignment from the assignee group. 0 The policies for the assignee group: 1. Only the assignee group manager can accept and start a project assignment that is assigned to the group. 2. Only the group manager can prepare the report according to the assignContract and send it to the assigner group. Only the group manager can send final result of the project. 113 3. Before the project is started, the group manager can set a default access policy for the entire project. The default access policy has the same fonnet of the job contract. The policy defines the general access settings of the entire project. There are also two choices of the default policy: overrode or un-overrode. 4. Inside a group, after inherited the default project policy, the access control follows the policies we introduced early. The access control policies of project assigning between groups belong to Iayer2 in the LBAC model. The two assignContracts are in the contract component of the interface between layer1 and layer2. The progress report and final result are in the report component of the interface. In MIDAS we implemented the Layer-based Access Control model, which shows the flexibility of LBAC: in different layers, according to different access control requirements, we can choose suitable polices. The access control information in different layers can be exchanged through the interface. 114 Summary Computer system becomes the fundamental component of the modern manufacturing industries. More and more information is generated and stored in computer system, and at the same time the system designer cannot assume that the system users are trustable, so that the security must be considered when a computer system is designed and implemented In this paper, we discussed what security means to a Virtual Enterprise system. The three basic components (authentication, access control and auditing) of the security subsystem are addressed. The main focus of this paper is the access control component, and other two components are briefly introduced. The essence of access control is to answer the question:” who can perform what action on which information?” To solve this question, low-level access control mechanisms and high-level access control models are needed. The basic mechanisms introduced in this paper include Access Matrix, Access Control Lists, Capability Lists and Authorization Relations. There classical access control models (Discretionary Access Control, Mandatory Access Control and Role-based Access Control) are discussed in detail. After analyzing the security requirements in the real collaborative environment, we pointed out the drawbacks of the Classical access control models. To overcome those drawbacks, the 115 Layer-based Access Control (LBAC) was proposed. LBAC captures the organization structure of subjects and the hierarchical decomposing structure of objects. According to the collaborative activities (task assigning), LBAC groups subjects and objects into different layers. Each layer has its own access control policies. And adjacent layers talk to each other through a layer interface. The interface contains two parts: contract and report. The contract is used to exchange the access control information and the report is used to exchange the object information. When a task is assigned to a subject, the subject belongs to a certain layer. And the subjects cannot shift out of the layer. LBAC makes the access control subsystem more flexible and extendable. It can adopt other access control models easily within each layer. Currently in MIDAS access control is only implemented in the process execution mode. The future work is to extend the LBAC policies to the author mode, and also the LRAC policies should be fine-gained, so that MIDAS can provide more precisely control of access. 116 References Argus-Systems (2001 ). PitBulI LX Secure Application Environment (white paper), http:I/www.argus-systems.com/public/dOCS/pitbull.lx.whitepaper.sae.pdf. Baldwin, R. and M. J. Chung (1995). “Design Methodology Management: A Formal Approach.“ Computer 28(2): 54-63. Bayliss, G M., A. Bowyer, et al. (1994). Virtual Manufacturing. Proceedings, CSG 94: Set-Theoretic Solid Modeling Techniques and Applications. Bell, D. E. and L. J. LaPadula (May 1973). Secure Computer Systems: Mathematical Foundations and Model. TR M74-244, The MITRE Corporation. Bowyer, A., G Bayliss, et al. (1996). “A Virtual Factory.“ lntemational Journal of Shape Modeling 2(4): 215-226. Bozdoc, M. The history of CAD, http://mbinfo.digitalrice.com/CAD-Historv.htm. Capretz, L. F. (2003). “A Brief History of Object-Oriented Approach.“ ACM SIGSOFT, Software Engineering Notes 28(2): 1-10. Castano, S. e. a. (1994). Database Securiy, Addison Wesley. CoulouriS, G, J. Dollimore, et al. (1998). Role and Task-based Access Control in the PerDiS Groupware Platform. Third ACM Workshop on Role-Based Access Control, George Mason University, Washington DC. dictionary, http://dictionam.reference.corn/search?g=process. Donald, D. L., N. Andreou, et al. (1999). The New Design: The Changing Role of Industrial Engineers in the Design Process Through the Use of Simulation. Proc. Winter Simulation Conf. EDS Digital Manufacturing, http://www.eds.com/productS/plrn/unigraphics nx/dmI. Erdmann, S. and J. Wortmann (1997). Enterprise Modelling with FUNSOFT Nets. 1st lntemational Enterprise Distributed Object Computing Conference 117 (EDOC '97), Gold Coast, AUSTRALIA. Ferraiolo, D. F., J. Cugini, et al. (1995). Role Based Access Control: Features and Motivations. Computer Security Applications Conference. Freedman, S. (1999). An Overview of Fully Integrated Digital Manufacturing Technology. Proc. Winter Simulation Conf., Phoenix, ACM. Gaines, B. R., D. H. Norrie, et al. (1995). Medfitogn lntellignt Information System Supmrting the Virtual Manpfacturing Enterprise. Proc. of IEEE lntemational Conference on Systems, Man and Cybernetics, New York. Gollmann, D. (1999). Computer Securiy, Ist edition, John Wiley & Sons. Harrison, M. H., W. L. Ruzzo, et al. (1976). “Protection in Operating System." Communications of the ACM 19(8): 461-471. Kang, M. H., J. S. Park, et al. (2001). Access cont_rol mechanisms for inter-organizationalworkflow. In Sixth ACM Symposium on Access Control Models and Technologies. Keyes, D. S. (1996). Design and Implementation of a Distributed Process Management Framework. Computer Science and Engineering. East Lansing, Michigan State University. Lhotka, R. Visual Basic .NET as a Fully Object-Oriented Language, http J/www.develogrcom/vb/article.phfl8821 1 1 . Lupu, E., Z. Milosevic, et al. (1999). Use of Roles and Policies for Speciming, and Managing a Virtual Enterprise. the 9th IEEE lntemational Workshop on Research Issues on Data Engineering: lnforrnation Technology for Virtual Enterprises (RIDE-VE’99), Sydney, Australia. Malone, T. W. and K. Crowston (1994). “The Interdisciplinary Study of Coordination.“ ACM Computing Surveys 26(1): 88-119. NIIIP (1996). The NIIIP Reference Architecture, www.niiip.org. OMG Unified Modeling Language, http://www.omg.orgruml/. Qin, Y. (2002). Manufacturing Infrastructure and Design Automation System 118 (MIDAS) with XML representation. Computer Science and Engineering. East Lansing, Michigan State University. Rahwan, I., R. Kowalczyk, et el. (2000). Virtual Enterprise Design - BDI Agents vs. Objects. Recent Advances in A_rt_ificia_l Intelligence in e-Commerce. R. a. L. Kowalczyk, M, Springer-Variag. Rentsch, T. (1982). “Object Orient Programming.“ A_C_M §lGPI=AN Notices 17(9): 51-57. Riddle, W. E. (1996). Fundamental Process Modeling Concepts“, published by Web, h_ttp://lsdis.cs.pgaedtr/activitjes/NSF-workflow/FundConc.html. Roeckle, H., G Schimpf, et al. (2000). Procengriented approach for role-finding to implement role-based securitv administration in a large industrial organization. the fifth ACM workshop on Role-based access control, Berlin, Germany. Routledge, N., L. Bird, et al. (2002). UML and XML scheme. the thirteenth Australasian conference on Database technologies, Melbourne, Victoria, Australia, Australian Computer Science Communications. Sandhu, S. R. and P. Samarati (1994). “Access Control: Principles and Practice." IEEE Communications Magazine: 40-48. Terzis, S. and P. Nixon (1998). Building the next generation groupware: A survey of groupware and its impact on the virtual enterprise. Thomas, D. (1989). “What's in an Object.“ Bfie 14(3): 231 -240. Thomas, R. K. and R. S. Sandhu (1997). Task-based Authorization Controls (IBAC): A Family of Models for Act_ive andfintemrise-oriented Authorization Management. the IFIO WGI1.3 Workshop on Database Security, Lake Tahoe, California. USBusinessReview (2001). Digital Factory, http://www.usbusineSS-review.com/01 09/05.html. W30 Extensible Markup Language (XML), mllwww.w3.orgr)_(MLI. Walton, J. and L. Whicker (1996). “Virtual Enterprise: Myth & Reality.“ J. Control. 119 Wang, A. I. (1999). Experience paper: Using XML to imflement a workflow tool. In 3rd Annual IASTED lntemational Conference Software Engineering and Applications, Scottsdale, Arizona, USA. Zha, X. F. (2002). “A knowledge intensive multi-agent framework for cooperative/collaborative design modeling and decision support of assemblies.“ Knowledge-based Systems 15(8): 493-506. 120 IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII lllllIIIIIIIIIjIII[III]lI