Presentation on theme: "IFIP 2000-1 Profs. Steven A. Demurjian and T.C. Ting J. Balthazar, H. Ren, and C. Phillips Computer Science & Engineering Department 191 Auditorium Road,"— Presentation transcript:
IFIP Profs. Steven A. Demurjian and T.C. Ting J. Balthazar, H. Ren, and C. Phillips Computer Science & Engineering Department 191 Auditorium Road, Box U-155 The University of Connecticut Storrs, Connecticut 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 *This work supported in part by a research contract from the Mitre Corporation (Eatontown, NJ) and a research grant from AFOSR
IFIP Overview Goals of Our Research Effort Goals of Our Research Effort Suns JINI Technology Suns JINI Technology A Software Architecture for Role-Based Security 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 Experimental Prototypes JINI Prototype of Role Based Approach Security Client Prototype Related Work Related Work Conclusions and Future Work Conclusions and Future Work
IFIP Goals of Our Research Effort Incorporation of Role-Based Approach within Distributed Resource Environment 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 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) Propose Security Solution for Distributed Applications for Clients and Services (Resources)
IFIP Suns JINI Technology Construct Distributed Applications Using JINI by 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 Resource Provides a Set of Services for Use by Clients (Users) and Other Resources (Services) A Service is Similar to a Public Method 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 Services Register with Lookup Service
IFIP Suns JINI Technology Key JINI Concepts and Terms Registration of Services via Leasing Mechanism 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 Leasing Supports High-Availability Registration and Renewal Process Upon Failure, Services Removed from Registry Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes Clients, Resources, Lookup Can Occupy Same or Different Computing Nodes
IFIP Suns 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
IFIP Proposed Software Architecture for Role-Based Security Many Current Lookup Services Many Current Lookup Services Successfully Dictates Service Utilization Requires Programmatic Solution for Security Does Not Selectively and Dynamically Control Access Based on Client Role Security of a Distributed Resource Should Selectively and Dynamically Control Client Access to Services Based on the Role Security of a Distributed Resource Should Selectively and Dynamically Control Client Access to Services Based on the Role Our Approach Our Approach Define Dedicated Resources to Authorize, Authenticate, and Enforce Security by Role Proposed Resources Role-Based Privileges, Authorization List, Security Registration
IFIP 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
IFIP Security Resources and Services Role-Based Privileges Resource Role-Based Privileges Resource Define User-role Grant/Revoke Access of Role to Resource Register Services Authorization List Resource Authorization List Resource Maintains Client Profile (Many Client Types) Client Profile and Authorize Role Services Security Registration Resource Security Registration Resource Register Client Service Identity Registration at Startup Uses IP Address Services of Resource Services of Resource Functionally Separated and Organized Resemble Method Definitions (OO)
IFIP The Services of the Role-Based Privilege Resource
IFIP The Services of the Authorization-List Resource
IFIP The Services of the Security Registration Resource
IFIP 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?
IFIP Two Experimental Prototypes JINI Prototype of Role Based Approach 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 Security Client Prototype Generic Tool Uses Three Resources and Their Services Role-Based Privileges Authorization-List Security Registration
IFIP 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().
IFIP 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 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
IFIP Experimental Prototype Two The Security Client Prototype Figure 4.3: Initial Security Client Screen.
IFIP Recall Security Resources and Services
IFIP Experimental Prototype Two Role-Based Privilege Resource & Services Figure 4.4: The Role-Based Privileges Services Screen
IFIP Experimental Prototype Two Authorization List Resource & Services Figure 4.5: The Authorization-List Services Screen.
IFIP Experimental Prototype Two Security Registration Resource & Services Figure 4.6: The Security Registration Services Screen.
IFIP Related Work Security Policy & Enforcement (OS Security) Security Policy & Enforcement (OS Security) Security Filters and Screens Header Encryption User-level Authen. IP Encapsulation Key Mgmt. Protocols Browser Security Use of Encryption Use of Encryption Access Control Securing Comm. Channel Establishing a Trusted Computer Base Network Services Kerberos and Charon Security: Mobile Agents 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
IFIP Conclusions For a Distributed Resource Environment For a Distributed Resource Environment Proposed & Explained a Role-Based Approach Authorize, Authenticate, and Enforce Presented an Software Architecture Containing 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 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
IFIP Future Work Negative Privileges 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 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 Concept available with JINI Leasing Allows Services to Expire Can Role-Based Privileges Also Expire?
IFIP Future Work Location of Client vs. Affect on Service 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 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 Integration of the the Two Prototypes Combining Both Prototypes into Working System Likely Semester Project during Fall 2000