1. IFIP 2000-1 Profs. Steven A. Demurjian Computer Science & Engineering Department 191 Auditorium Road, Box U-155 The University of Connecticut Storrs, Connecticut 06269-3155 http://www.engr.uconn.edu/~steve steve@engr.uconn.edu Security for Distributed Computing Security for Distributed Computing  Security Issues for Distributed Computing  A Proposed Distributed Security Framework  Role-Based Security in a Distributed Resource Environment

2. IFIP 2000-2 Security Issues for Distributed Computing  Background and Motivation  What are Key Distributed Security Issues?  What are Major/Underlying Security Concepts?  What are Available Security Approaches?  Identifying Key Distributed Security Requirements  Focusing on Discretionary Access Control (DAC) and User-Role Based Security (URBS) for OO  Propose Preliminary Security Techniques to Address OO and Non-OO Legacy/COTS Appls.

3. IFIP 2000-3 Security for Distributed Applications Comprised of DBs, Legacy, COTS, etc. Legacy COTS Database NETWORK Java Client Java Client How is Security Handled for Individual Systems? What about Distributed Security? Security Issues for New Clients? New Servers? Across Network? What if Security Never Available for Legacy/COTS/Database? Security Policy, Model, and Enforcement?

4. IFIP 2000-4 Identifying Key Security Requirements What are Major Security Concepts?  Authentication  Is the Client who S/he Says they are?  Authorization  Does the Client have Permission to do what S/he Wants?  Privacy  Is Anyone Intercepting Client/Server Communications?  Enforcement Mechanism  Centralized and Distributed “Code”  Enforces Security Policy at Runtime

5. IFIP 2000-5 Identifying Key Security Requirements What are Underlying Security Concepts?  Assurance  Are the Security Privileges for Each Client Adequate to Support their Activities?  Do the Security Privileges for Each Client Meet but Not Exceed their Capabilities?  Consistency  Are the Defined Security Privileges for Each Client Internally Consistent?  Least-Privilege Principle: Just Enough Access  Are the Defined Security Privileges for Related Clients Globally Consistent?  Mutual-Exclusion: Read for Some-Write for Others

6. IFIP 2000-6 Identifying Key Security Requirements What are Available Security Approaches?  Mandatory Access Control (MAC)  Bell/Lapadula Security Model  Security Levels for Data Items  Access Based on Clearance of User  Discretionary Access Control (DAC)  Richer Set of Access Modes  Focused on Application Needs/Requirements  User-Role Based Security (URBS)  Variant of DAC  Responsibilities of Users Guiding Factor  Facilitate User Interactions while Simultaneously Protecting Sensitive Data

7. IFIP 2000-7 Identifying Key Security Requirements Three Categories of Questions  Questions on Information Access and Flow  User Privileges key to Security Policy  Information for Users and Between Users  Questions on Security Handlers and Processors  Manage/Enforce Runtime Security Policy  Coordination Across EC Nodes  Questions on Needs of Legacy/COTS Appls.  Integrated, Interoperative Distributed Application will have New Apps., Legacy/COTS, Future COTS

8. IFIP 2000-8 Questions on Information Access and Flow  Who Can See What Information at What Time?  What Are the Security Requirements for Each User Against Individual Legacy/cots Systems and for the Distributed Application?  What Information Needs to Be Sent to Which Users at What Time?  What Information Should Be “Pushed” in an Automated Fashion to Different Users at Regular Intervals?

9. IFIP 2000-9 Questions on Information Access and Flow  What Information Needs to Be Available to Which Users at What Time?  What Information Needs to Be “Pulled” On- demand to Satisfy Different User Needs in Time-critical Situations  How Are Changing User Requirements Addressed Within the Distributed Computing Application?  Are User Privileges Static for the Distributed Computing Application?  Can User Privileges Change Based on the “Context” and “State” of Application?

10. IFIP 2000-10 Questions on Security Handlers/Processing  What Security Techniques Are  Needed to Insure That the Correct Information Is Sent to the Appropriate Users at Right Time?  Necessary to Insure That Exactly Enough Information and No More Is Available to Appropriate Users at Optimal Times?  Required to Allow As Much Information As Possible to Be Available on Demand to Authorized Users?

11. IFIP 2000-11 Questions on Security Handlers/Processing  How Does the Design by Composition of a Distributed Computing Application Impact on Both the Security and Delivery of Information?  Is the Composition of Its “Secure” Components Also Secure, Thereby Allowing the Delivery of Information?  Can We Design Reusable Security Components That Can Be Composed on Demand to Support Dynamic Security Needs in a Distributed Setting?   What Is the Impact of Legacy/cots Applications on Delivering the Information?

12. IFIP 2000-12 Questions on Security Handlers/Processing   How Does Distribution Affect Security Policy Definition and Enforcement?   Are Security Handlers/enforcement Mechanisms Centralized And/or Distributed to Support Multiple, Diverse Security Policies?   Are There Customized Security Handlers/enforcement Mechanisms at Different Levels of Organizational Hierarchy?  Does the Organizational Hierarchy Dictate the Interactions of the Security Handlers for a Unified Enforcement Mechanism for Entire Distributed System?

13. IFIP 2000-13 Questions on Legacy/COTS Applications  When Legacy/cots Appls. Are Placed Into Distributed, Interoperable Environment:  At What Level, If Any, Is Secure Access Available?  Does the Application Require That Secure Access Be Addressed?  How Is Security Added If It Is Not Present? What Techniques Are Needed to Control Access to Legacy/COTS?  What Is the Impact of New Programming Languages (Procedural, Object-oriented, Etc.) And Paradigms?

14. IFIP 2000-14 Focusing on DAC and URBS   We’ve Explored DAC/URBS for OO Systems and Applications   Potential Public Methods on All Classes   Role-Based Approach:  User Role Determines which Potential Public Methods are Available  Automatically Generate Mechanism to Enforce the Security Policy at Runtime  Allow Software Tools to Look-and-Feel Different Dynamically Based on Role   Approaches have Employed Inheritance, Generics, and Exceptions in C++/Ada95 Languages   Leverage Results as Starting Point

15. IFIP 2000-15 Legacy/COTS Applications  Interoperability of Legacy/COTS in a Distributed Environment  Security Issues in Interoperative, Distributed Environment  Can DAC/URBS be Exploited?  How are OO Legacy/COTS Handled?  How are Non-OO Legacy/COTS Handled?  How are New Java/C++ Appls. Incorporated?  Can Java Security Capabilities be Utilized?  What Does CORBA/ORBs have to Offer?  What about other Middleware (e.g. JINI)?  Explore Some Preliminary Ideas on Select Issues

16. IFIP 2000-16 Security for OO Legacy/COTS  For OO Legacy/COTS, High Likelihood of Class Based Programming Interface  Utilize Reviewed DAC/URBS Approaches: User-Role Subclassing Approach OO Classes that form the Programming Interface to Legacy/COTs, e.g., PatientRecord Nurse_PatientRecord and MD_PatientRecord Classes Customer/User Applications Against Nurse/MD Classes PatientRecord_Exception Class Extends PatientRec with try/catch/throw Basic Exception Approach OO Classes that form the Programming Interface to Legacy/COTs, e.g., PatientRecord Customer/User Applications Against PatientRecord_Excp

17. IFIP 2000-17 Security for Non-OO Legacy/COTS  For Non-OO Legacy/COTS, Programming Interface Likely a Set of System Functions  Utilize Reviewed DAC/URBS Approaches: User-Role Subclassing Approach Set of System Functions that form the Pgmmg. Interface to Legacy or COTS Customer/User Applications Against Exception Classes Basic Exception Approach Set of System Functions that form the Pgmmg. Interface to Legacy or COTS OO Wrapper of Classes with Methods that Invoke Functions User-Role Subclasses, e.g., MD_PatientRecord for Customer/User Applications Against User-Role Subclasses OO Wrapper of Classes with Methods that Invoke Functions Exception Classes Extend OO Wrapper Classes-try/catch/thw

18. IFIP 2000-18 A Distributed Security Framework Motivation and Issues  What is Needed for the Definition and Realization of Security for a Distributed Application?  How can we Dynamically Construct and Maintain Security for a Distributed Application?  Application Requirements Change Over Time  Seamless Transition for Changes  Transparency from both User and Distributed Application Perspectives  What are Parts of Distributed Security Framework?

19. IFIP 2000-19 A Distributed Security Framework  Distributed Security Policy Definition, Planning, and Management  Exactly Define Security Policy  Manage Policy in Changing Environment  Formal Security Model w. Reusable Components  Formal Realization of Security Policy  Reusable “Security” Components  Security Handlers & Enforcement Mechanism  Run-time Techniques and Processes  Allows Dynamic Changes to Policy to be Seamless and Transparently Made

20. IFIP 2000-20 L + SH DB + SH Java Client Java Client Legacy Client DB Client COTS Client L + SH CO+ SHDB + SH Server + SHL + SH CO+ SH Server + SH DB + SH Formal Security Model Distributed Security Policy Reusable Security Components Enforcement Mechanism Collection of SHs L: Legacy CO: COTS DB: Database SH: Security Handler A Distributed Security Framework Interactions and Dependencies

21. IFIP 2000-21 Distributed Security Policy Definition, Planning, and Management  Interplay of Security Requirements, Security Officers, Users, Components and Overall System  Minimal Effort in Distributed Setting - CORBA Has Services for  Confidentiality, Integrity, Accountability, and Availability  But, No Cohesive CORBA Service Ties Them with Authorization, Authentication, and Privacy   Difficult to Accomplish in Distributed Setting  Must Understand All Constituent Systems  Interplay of Stakeholders, Users, Sec. Officers

22. IFIP 2000-22 Formal Security Model with Reusable Components  Constructive Means to Capture Distributed Security Policy  Transitional Intermediate Form to Actual “Reusable” Security Components  Possible Approach  Upgrade URDH/Role-Based OO Work to Distributed Service-Based Approach  Utilize DRE for Analyzing Reusability of Security Components  Change/Extend DRE for Analyzing Security Dependencies - e.g., Chaining of Calls

23. IFIP 2000-23 Security Handlers and Enforcement Mechanism  Provide Concrete Means That Distributed Security Policy As Captured by the Formal Security Model Is Dynamically Attained in Runtime Setting  Can our Prior Approaches be Leveraged?  URSA, UCLA, BEA, GEA, etc.  Agent-Based URBS  Security Capabilities of Java  What are Potential Middleware Solutions?  CORBA  JINI  XML (XMI)

24. IFIP 2000-24 Contributions of the Framework  Integration of URBS Techniques and Reusability Analysis May Lead to …  Security Components That Are Reusable Within an Organization’s Domain  Security Components Proven Correct When Reused, Carry Correctness to Other Settings  Assurance to Security Officers That the Defined Policy Continues to Be Enforced  Modifications to Dependency Analysis (DRE) to Include Security Requirements and Roles Offers Another Dimension on Reusable D & D

25. IFIP 2000-25 Profs. Steven A. Demurjian and T.C. Ting J. Balthazar, H. Ren, and C. Phillips Computer Science & Engineering Dept. 191 Auditorium Road, Box U-155 The University of Connecticut Storrs, Connecticut 06269-3155 http://www.engr.uconn.edu/~steve steve@engr.uconn.edu Role-Based Security in a Distributed Resource Environment* Role-Based Security in a Distributed Resource Environment* Dr. Paul Barr The MITRE Corp 145 Wyckoff Road Eatontown, New Jersey 07724 poobarr@mitre.org *This work presented at IFIP WG 11.3 on DB Security in August 2000, and supported in part by a research contract from the Mitre Corporation (Eatontown, NJ) and a research grant from AFOSR

26. IFIP 2000-26Overview  Motivation and Goals of Our Research Effort  Sun’s JINI Technology  A Software Architecture for Role-Based Security  Proposed Software Architecture  Security Resources and Services  Security Client and Resource Interactions  Client Interactions and Processing  Experimental Prototypes  JINI Prototype of Role Based Approach  Security Client Prototype  Related Work  Conclusions and Future Work

27. IFIP 2000-27 Overview of the Security Process for a Distributed Application  Focus on Role-Based Security Within Application  Clients Play Role  Role Dictates Look and Feel of Client Software  Role Passed Along to “Systems” that Comprise Distributed Application  Distributed Application Must  Contain “Security Software”  How is Security Captured?  How is Security Enforced?  How Do Clients Interact with Distributed Application?

28. IFIP 2000-28 Goals of Our Research Effort  Incorporation of Role-Based Approach within Distributed Resource Environment  Highly-Available Distributed Applications Constructed Using Middleware Tools  Demonstrate Use of JINI to Provide Selective Access of Clients to Resources Based on Role  Propose Software Architecture and Role-Based Security Model for  Authorization of Clients Based on Role  Authentication of Clients and Resources  Enforcement so Clients Only Use Authorized Services (of Resource)  Propose Security Solution for Distributed Applications for Clients and Services (Resources)

29. IFIP 2000-29 Sun’s JINI Technology  Construct Distributed Applications Using JINI by  Federating Groups of Users  Resources Provide Services for Users  A Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services)  A Service is Similar to a Public Method  Exportable - Analogous to API  Any Entity Utilized by Person or Program  Samples Include:  Computation, Persistent Store, Printer, Sensor  Software Filter, Real-Time Data Source  Services: Concrete Interfaces of Components  Services Register with Lookup Service

30. IFIP 2000-30 Sun’s JINI Technology Key JINI Concepts and Terms  Registration of Services via Leasing Mechanism  Resource Leases Services to Lookup Service  Resources Renew Services Prior to Expiration  If not, Services Become Unavailable  Lookup Service Maintains Registry  Services as Available “Components ”  Leasing Supports High-Availability  Registration and Renewal Process  Upon Failure, Services Removed from Registry  Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes

31. IFIP 2000-31 Sun’s JINI Technology Join, Lookup, and Service Invocation Client Resource Service Object Service Attributes Lookup Service Request Service AddCourse(CSE900) Return Service Proxy to AddCourse( ) JoinJoin Register & Lease Services CourseDB Class Contains Method AddCourse ( ) 1. Client Invokes AddCourse(CSE900) on Resource 2. Resource Returns Status of Invocation Service Invocation via Proxy by Transparent RMI Call Service Object Service Attributes Registry of Entries

32. IFIP 2000-32 Security within JINI Limitations and Potential  Provides Minimal Support for Application Level Security  Registration Process by Resources of Services Doesn’t Allow “Who Can Use Which Service”  Consequently, Resources Using JINI Would Require Programmatic Solution for Security  Requires Code-Level Changes  Recompilation and Rebuild  Can’t Adjust Dynamically When Privileges Must be Changed  Can a Distributed Resource Environment (JINI) be Exploited to Allow Role-Based Security Consistent with its Philosophy and Use?

33. IFIP 2000-33 Role-Based Security within JINI A Proposed Solution Approach  Define Resources to Manage and Control Security  Role-Based Privileges:  What are the Defined User Roles (e.g. URDH)?  Which Role can Use Which Service(s) of Each Resource?  Allow Access Down to Method Level  Authorization List:  Who are the Users?  What are Their Authorized Role(s)?  Security Registration:  Who are Active Users?  How is User Uniquely Identified?

34. IFIP 2000-34 Proposed Software Architecture for Role-Based Security Resources Provide ServicesClients Using Services Figure 3.1: General Architecture of Clients and Resources. Role-Based Privileges Authorization List Security Registration Legacy COTS Database Lookup Service Lookup Service Java Client Java Client Legacy Client Database Client Software Agent COTS Client

35. IFIP 2000-35 Security Resources and Services  Role-Based Privileges Resource  Define User-role  Grant/Revoke Access of Role to Resource  Register Services  Authorization List Resource  Maintains Client Profile (Many Client Types)  Client Profile and Authorize Role Services  Security Registration Resource  Register Client Service  Identity Registration at Startup  Uses IP Address  Security Client  Allow Security Officer to Set, Change, Monitor, and Manage the Three Security Resources

36. IFIP 2000-36 Defining a Base Line Security Model for Distributed Computing  Definition 1: A Resource Is a System (E.G., A Legacy, COTS, Database, Web Server, Etc.) That Provides Functions for the Distributed Application Via a Collection of N Services.  Definition 2: A Service Is Composed of Multiple Methods  Each Method Is Akin to OO Method  Each Method Represents a Subset of the Functionality Provided by the Service  Definition 3  Definition 3: A Method of a Service Is Characterized by a Signature

37. IFIP 2000-37 Defining a Base Line Security Model for Distributed Computing   Definitions 4:  Each Resource Has a Unique Resource Identifier to Differentiate Between Replicated Resources   Definitions 5:  Each Service Has a Unique Service Identifier to Distinguish Services Within a Particular Resource   Definitions 6:  Each Method Has a Unique Method Signature to Distinguish Methods of a Service

38. IFIP 2000-38 Defining a Base Line Security Model for Distributed Computing  Definition 7: A User Role, UR, Is a Uniquely Named Entity for a Specific Set of Responsibilities Against an Application With Privileges Are Granted and Revoked As Follows:  UR Can Be Granted Access to Resource R, Implying It Can Utilize All of R's Services, and Their Methods  UR Can Be Granted Access to a Subset of the Services of Resource R, Denoting That UR Can Utilize All of the Methods Defined by That Subset  UR Can Be Granted Specific Access to Individual Methods Via Triple

39. IFIP 2000-39 Role-Based Privileges Resource  Define User-role, Grant/revoke Access of Role to Resource, and Registration of Resource’s Services  Maintains Following Information:  Resource List Indexed by and All of URs Granted Access to Resource  Service List Indexed by and All URs Granted Access to Service  Method List Indexed by and All URs Granted Access to Each Method  User-role List Indexed by, and for Each UR All Resources, Services, Methods, Granted Access

40. IFIP 2000-40 The Services of the Role-Based Privilege Resource

41. IFIP 2000-41 Authorization List Resource  Maintains Client Profile (Many Client Types) and Ability to Authorize Role Services   Definition 8:  A Client Profile, CP, Characterizes All of the Pertinent Information on Client (User, Tool, Software Agent, Etc.)  A CP Used by Resource to Dynamically Verify Whether a Client Can Access the Desired Triple of  Addresses Issues Such As: Has Client Registered? Is Client ID Accurate? Etc.

42. IFIP 2000-42 The Services of the Authorization-List Resource

43. IFIP 2000-43 Security Registration Resource  Utilized to Register Client Service, Identity Registration at Startup, and Uses IP Address  Usage by Client  When Client First Begins Session  Establish Client Id, IP Address, and User Role  Usage by Resource to Determine If a Client Has Registered  Usage by Security Client to Maintain and Query Privileges

44. IFIP 2000-44 The Services of the Security Registration Resource

45. IFIP 2000-45 Security Client and Resource Interactions Figure 3.3: Security Client and Database Resource Interactions. Role-Based Privileges Authorization List Security Registration Lookup Service Security Client Find_Client(C_Id, IP_Addr); Find_All_Active_Clients(); Discover Service Return Proxy General Resource Grant_UR_Client(UR_Id, C_Id); Revoke_UR_Client(UR, C_Id); Find_AllUR_Client(C_Id); Find_All_Clients_UR(UR); Create_New_Role(UR_Name, UR_Disc, UR_Id); Delete_Role(UR_Id); Find_UR_Name(UR_Name); Find_UR_Id(UR_Id); Grant_Resource(UR_Id, R_Id); Grant_Service(UR_Id, R_Id, S_Id); Grant_Method(UR_Id, R_Id, S_Id, M_Id); Revoke_Resource(UR, R_Id); Revoke_Service(UR, R_Id, S_Id); Revoke_Method(UR, R_Id, S_Id, M_Id); Find_AllUR_Resource(UR,R_Id); Find_AllUR_Service(UR,R_Id,S_Id); Find_AllUR_Method(UR,R_Id,S_Id,M_Id); Find_UR_Privileges(UR); Register_Resource(R_Id); Register_Service(R_Id, S_Id); Register_Method(R_Id, S_Id, M_Id); UnRegister_Resource(R_Id); UnRegister_Service(R_Id, S_Id); UnRegister_Method(R_Id, S_Id, M_Id); Create_New_Client(C_Id); Delete_Client(C_Id); Find_Client(C_Id); Find_All_Clients();

46. IFIP 2000-46 8. Check_Privileges(UR,R_Id,S_Id,M_Id); Client Interactions and Processing Database Resource Figure 3.4: Client Interactions and Service Invocations. Role-Based Privileges Authorization List Security Registration Lookup Service GUI Client 1. Register_Client(C_Id, IP_Addr,UR); 2. Verify_UR_Client(UR,C_Id); Discover Service Return Proxy 3. Client OK? 4. Registration OK? 5. ModifyAttr(C_ID,UR,Value) 6.IsClient_Registered(C_ID) 7. Registration OK? 9. Privileges OK? 10. Modification OK?

47. IFIP 2000-47 Two Experimental Prototypes  JINI Prototype of Role Based Approach  University Database (UDB)  Initial GUI for Sign In (Authorization List)  Student/faculty GUI Client (Coursedb)  Access to Methods Limited Based on Role (Ex: Only Student Can Enroll in a Course)  Security Client Prototype  Generic Tool  Uses Three Resources and Their Services  Role-Based Privileges  Authorization-List  Security Registration

48. IFIP 2000-48 Experimental Prototype One JINI Prototype of Role Based Approach Figure 4.1: An Architecture of URBS based on JINI Technology. Java GUI Client1 JINI Lookup Service Author. List Res. (copy 2) Author. List Res. (copy 1) Role-Based Privileges & Sec. Reg. Java GUI Client2 CourseDB Resource (copy 1) CourseDB Resource (copy 2) Role-Based Privileges & Sec. Reg. DBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse(); UpdateCourse().

49. IFIP 2000-49 Experimental Prototype One Execution Process Figure 4.2: Execution Process for Architecture. Java GUI Client1 JINI Lookup Service Role-Base Privileges & Sec. Reg. 1a, 5a 1b, 5b 2 4 6 CourseDB Resource 8a 9a 8b 9b 10 7a 7b Author. List Res. 3aa3b 1a. Discover Register_Client Service 1b. Return Service Proxy 2. Register the Client 3a. Is Client Authorized? 3b. Succeed - return Role 4. Return Success or Failure 5a. Discover CourseDB Service 5b. Return Service Proxy 6. Invoke a Method, e.g., Invoke EnrollCourse() 7a. Discover Role-Based Priv. & Sec. Reg. Services 7b. Return Service Proxies 8a. Is Client Registered? 8b. Return Yes or No 9a. Can Client Invoke Method? 10. addCourse() or do nothing

50. IFIP 2000-50 Experimental Prototype Two The Security Client Prototype Figure 4.3: Initial Security Client Screen.

51. IFIP 2000-51 Recall Security Resources and Services

52. IFIP 2000-52 Experimental Prototype Two Role-Based Privilege Resource & Services Figure 4.4: The Role-Based Privileges Services Screen

53. IFIP 2000-53 Experimental Prototype Two Authorization List Resource & Services Figure 4.5: The Authorization-List Services Screen.

54. IFIP 2000-54 Experimental Prototype Two Security Registration Resource & Services Figure 4.6: The Security Registration Services Screen.

55. IFIP 2000-55 Related Work  Security Policy & Enforcement (OS Security)  Security Filters and Screens  Header Encryption  User-level Authen.  IP Encapsulation  Key Mgmt. Protocols  Browser Security  Use of Encryption  Access Control  Securing Comm. Channel  Establishing a Trusted Computer Base  Network Services  Kerberos & Charon  Security: Mobile Agents  Saga Security Architecture  Access Tokens  Control Vectors  Security Monitor  Concordia  Storage Protection  Transmission Protection  Server Resource Protection  Other Topics  Trust Appraisal  Metric Analysis  Short-lived Certificates  Seamless Object Authentication

56. IFIP 2000-56Conclusions  For a Distributed Resource Environment  Proposed & Explained a Role-Based Approach  Authorize, Authenticate, and Enforce  Presented an Software Architecture Containing  Role-Based Security Model for a Distributed Resource Environment  Security Registration, Authorization-List, and Role-based Privileges Resources  Developed Two Independent Prototypes  JINI-Based Prototype for Role-Based Security Model that Allows Clients to Access Resources Based on Role  Security Client for Establishing Privileges

57. IFIP 2000-57 Future Work  Negative Privileges  Chaining of Resource Invocations  Client Uses S1 on R1 that Calls S2 on R2  Client Authorized to S1 but Not S2  Multiple Security Clients  What Happens When Multiple Security Clients Attempt to Modify Privileges at Same Time?  Is Data Consistency Assured?  Leasing Concept available with JINI  Leasing Allows Services to Expire  Can Role-Based Privileges Also Expire?

58. IFIP 2000-58 Future Work  Location of Client vs. Affect on Service  What if Client in on Local Intranet?  What if Client is on WAN?  Are Privileges Different?  Tracking Computation for Identification Purposes  Currently Require Name, Role, IP Addr, Port #  How is this Tracked when Dynamic IP Addresses are Utilized?  Integration of the the Two Prototypes  Combining Both Prototypes into Working System  Likely Semester Project during Fall 2000