|
(1) This is a group project. Submit one report for your group. Organize your report as an engineering report that defines the architecture of a system, describes your approach to implementing the components, tests the system, and provides an evaluation of the strengths and weaknesses of the system. The body of your report should not exceed 10 pages. Attach your programs as appendices. (2) Use Java as your programming lanuage and environment. (3) Weights: the written report plus programs 15 points toward final grade; team demo of the working system, another 5 points. (4) Use these resources:
|
Consider a distributed system consisting of one or more user workstations, a file server, a directory server, and a print server. The file server stores and accesses files via commands like CREATE, DELETE, OPEN, CLOSE, READ, WRITE. The directory server implements commands like CREATE, DELETE, ENTER, REMOVE, and SEARCH. The print server implements commands like PRINT and ABORT.
On the user workstation, you want to build a simple command interface that lets you log in and then issue file, directory, and print commands. A command consists of a single line started by a command name and followed by its arguments. You want to demonstrate that you can create and delete files and directories and cause them to be printed.
Implement the workstation command interface, file server, directory server, and print server as distinct Java virtual machines (VM's). The VM's simulate the separate servers. Use the Java Remote Machine Interface (RMI) for communication between the VM's. Set up the simulation so that the VM's can be on different physical machines by using TCP and sockets for the communication methods between them. Java provides libraries for TCP and RMI.
Simulate the file server by passing the commands staight through to your host OS with the Java file access methods. In other words, use your host file system and simply provide an interface to it through your simulated file server. Do likewise for the directory and print servers. Java has class libraries that allow you to use the file and directory system directly. You may use the actual names of file and directory commands rather than the generic ones mentioned above.
Your command interface needs to include a login protocol and then to recognize the names of the commands and pass them to the appropriate server for execution. Thus a command "mkdir name" would be passed to the Java "mkdir" method in the simulated directory server with "name" as the argument.
Once you get these components working, create a test suite that demonstrates the operation of all the commands in the distributed system. Capture some samples of the traffic between the servers to demonstrate that the communications between VM's are working properly. Try to include a test where at least one of the servers is on a physically distinct machine.
Once the base system is working, extend it to provide authentication. This will simulate the situation in a real environment, where you want to restrict the use of the network and its serves to authorized users. Authentication will be handled by adding an authentication server (AS) and some protocols to the interactions between your other servers.
Initially, when a user signs on to the workstation, the user communicates with a login protocol. The login protocol asks for username and password. It passes both to the authentication server (AS). The AS returns either an error message or a ticket. The ticket contains a ticket number, a certificate from the AS saying that the user has been validated and is authorized to use system resources and an expiration time. The ticket is no longer valid after the expiration time. All accesses to the file, directory, and print servers must be modified to require a valid, unexpired ticket. These servers should refuse to work without a proper ticket. The AS maintains an internal record of the logged in user with a time stamp of the last time the user's login was validated. If the login is not re-validated by an expiration time (the sum of the time stamp plus a standard interval, e.g., 1 minute), the AS deletes the record.
In a real system, the initial communication from workstation to AS will be encrypted (to prevent eavesdropping by network packet sniffing) and the ticket will be digitally signed. You do NOT have to implement any of these encryption aspects. We are trying to simulate the function of the authentication tickets without the (important) details of their encryption.
We need a method of dealing with the automatic renewal of expired tickets. One way to handle this is to have the user's workstation regularly send a message to the AS indicating the user logged in there. If the AS already has a login record for that user, it simply updates the time stamp. Otherwise it sends a message back to the workstation indicating that that user's login in not authorized, which should trigger an automatic logout.
If any of the other servers (file, directory, print) gets an expired ticket, it tells the requestor that the ticket is expired; the requestor must submit the old ticket to the AS and ask for a renewal, which will be issued as long as the AS has a record that the user is still validly logged in.
When you get this working, create test scripts that show how the system responds to commands when tickets are valid and when they are invalid. Capture the traffic generated by a command to demonstrate that tickets are flowing properly in the system.
(1) Start by everyone on the team reading the Silberschatz chapters on distributed computing and security.
(2) Designate one person on your team to be the chief architect -- this person has the final say on what will be implemented and how components built by team members integrate together.
(3) Then implement the base system (workstation, file, directory, and print servers) in Java as outlined above. Create test scripts and capture some inter-server traffic to demonstrate the proper internal flows.
(4) In parallel with step 2, task one member of the team to take the lead to draft the protocols for the AS to use for issuing, validating, and renewing tickets. The whole team must sign off on the protocols.
(5) Extend your base system by adding the authentication protocols. Create test scripts and capture some inter-server traffic to demonstrate the proper internal flow.