User Role Based Security for Object-Oriented Systems/Applications

1. User Role Based Securityfor Object-Oriented Systems/Applications M.-Y. Hu, S. Demurjian, T.C. Ting Computer Science & Engineering Department The University of Connecticut Storrs, Connecticut 06269-3155 {steve, ting@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818

2. Overview of Presentation • Object-Oriented Design Model Concepts • Review: Approaches/Concepts of Security • Motivation of URBS for OO • User Role Based Security for Discretionary Access Control • Concepts and Issues • URBS Example for SDEs • Security Issues for OO Paradigm • URBS Approaches - OO and C++ • Advanced Security Code Generation • Software Architectures for URBS • Reflections and Comments

3. An Object-Oriented Design Model • Assumptions of OO Design Model • Vocabulary: • What are Object Types? • Attributes? • Methods? • Public Interface vs. Hidden Implementation • Concept of a Profile • Inheritance and its Variants

4. OTs, Attributes, and Methods

5. Encapsulation and Hiding

6. Profiles to Track Design Data • Profiles Contain Detailed Requirements on the Semantic Contex(n)t for All Constructs of Application • Force SWEs to Supply Detailed Design Info. As Application is Designed • All Profiles Share Following: • [Defn. 6:] A base profile (BP) contains: a name for the feature or construct and a prose description for its purpose within application. • We'll Focus on Non-Security Constructs • We'll Provide Examples via earlier Prototype (ADAM) and Health Care Application (HCA)

7. Attribute Profile

8. Method Profile

9. Object Type Profile

10. Object Type Profile

11. Inheritance Variants • Distinguish Between Type and Instance Level • Employ a Hierarchy to Define Choices: • T-LEVEL: Variants that Dictate the Information and Behavior that is Inherited by Subtype from Supertype • I-LEVEL: Variants that Relate to If and How a Subtype is Instantiated ISA / +-----+ +---------+ / T-LEVEL I-LEVEL / / | +---+ / +----+ | / / | FULL PRIV1 PRIV2 RESTR CONSTRUCTOR / | +--+ | / | ABSTR LEAF(DB) REGULAR(PL)

12. Four T-LEVEL Combinations • What Can be Inherited? • Who Can See What When?

13. What Dictates Correct Variant? • The OT's Role in Application: • FULL for Unlimited Cooperative Design • PRIV1 for Cooperative Design, No Priv. Data • PRIV2 Limits Access to PPI methods • RESTR Requires Intervention of URBS • The Responsibility SWEs w.r.t. Application • A Time Factor which Mandates Different Interpretations in a Application's Lifetime: • Initially ISA - FULL • Design Partitioned Among Multiple SWEs - PRIV1, PRIV2, and RESTR May be Chosen • User Role(s) of SWEs from URDH are Utilized! • Trying to Integrate Security Concepts into Design

14. C++ Equivalents for Variants • To Understand Different Variants, Let's Consider C++ Analogs for Design Model Constructs • Provides a General Indication of Impact of Different Inheritance Combinations on Code Generation

15. Impact on Code Generation SUPPOSE: OT1 = (D1, M1), with M1=(HM1,PM1) | OT2 = (D2, M2), with M2=(HM2,PM2) FULL: OT2 = (OTName2, {D1,D2, {M1, M2) C++ : class OT1 { protected: D1, HM1; public : PM1; class OT2: public OT1 { protected: D2, HM2; public : PM2; Notice: OT2 inherits all Data and Methods Only PM1, PM2 have Potential to be Public!

16. Impact on Code Generation PRIV1: OT2 = (OTName2, {D2, {M1, M2) C++ : class OT1 { private : D1; protected: HM1; public : PM1; class OT2: public OT1 { protected: D2, HM2; public : PM2; PRIV2: OT2 = (OTName2, {D2, {PM1, M2) C++ : class OT1 { private : D1, HM1; public : PM1; class OT2: public OT1 { protected: D2, HM2; public : PM2;

17. Three I-LEVEL Combinations • ABSTR: Short for Abstract Class • Instantiation of a Subtype is Neither Desirable Nor Possible • LEAF: Database Version • Creation (Deletion) of Instances at the Leaves • REGULAR: Programming Version • Creation/Deletion at Any Hierarchy Node • Implications on University Example? Person / / Student Employee / / UnderGrad Graduate Faculty

18. Impact on Code Generation • No Changes to Previous Slides on What Gets Inherited • ABSTR: At Least One Pure Abstract Method • LEAF: Instantiate at Leaf Nodes • REGULAR: Generate Public Constructors • What Happens With Mixed Inheritance Variants? • Which Ones Make Sense? • Which Ones Cause Conflicts? GENERATE protected constructors in C++! PERSON - constructor is protected | EMPLOYEE - constructor is protected | FACULTY - constructor is public

19. C++: (REGULAR, FULL) Inheritance

20. C++: (LEAF, RESTR1) Inheritance class Record : public Object { // ATTRIBUTES: private: int RecNo; // A unique record number protected: // System defined CONSTRUCTOR & DESTRUCTOR: Prescription(); virtual ~Prescription(); // **** System defined protected methods. protected: void SetRecNo(float toSet); // **** System defined public methods. public: void PrintRecNo(); float GetRecNo(); void printallattrs(); ;

21. Glossary of Protection and Security Terms • Access Control List • List of Principals (User, Process, …) Authorized to have Access to Some Object • Authenticate • Verify Identity of Principal Making Request • Authorize • Grant Principal Access to Information • Capability • Unforgeable Ticket as Proof of Authorization of Presenter to Access Named Object • Capability List • List of Protected Objects which Likewise List Authorized Principles

22. Glossary of Protection and Security Terms • Certify • Verify Accuracy, Correctness, & Completeness of Security/Protection Mechanism • Confinement • Restricting What a Process Can Do to with Authorized Objects • Domain • Objects Currently Accessed by Principal • (De)Encryption • De(Encoding) of Data According to Transformation Key for Transmission/Storage • Grant • Authorize Access to Objects by Principals

23. Glossary of Protection and Security Terms • Password • Encrypted Character String to Authenticate Identity of Individual • Permission • Form of Allowed Access to Object (R, W, RW) • Principal • Entity (Person/Process/etc.) to Which Authorizations are Granted • Privacy • Ability to Decide Whether, When, and to Whom Information is Released • Propagation • Principal Passing on Authorization to Object to Another Principal

24. Glossary of Protection and Security Terms • Protected Object • Known Object whose Internal Structure is Inaccessible Except by Protection System • Protection & Security • Mechanisms and Techniques to Control Access to Information by Executing Programs • Revoke • Remove Previously Authorized Access from Principals • Ticket-Oriented • Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized Glossary from: Saltzer and Schroeder, “The Protection of Information in Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.

25. ReviewFundamental Security Issues • Software Engineers Can Write Complex Programs Limited by Intellectual Capabilities • OS Designer Must Create Protection Scheme that Can’t be Bypassed by Current and Future Software • Users and Processes Initiators • Users have Dedicated and Shared Resources • Resources Shared by User Groups vs. Resources Globally Shared • Users Spawn Processes that Access Resources • Processes May be Local or Remote (on Another Machine Connected via Network) • Protection System of OS Must Support Above According to Organization’s Admin. Policy

26. Review Policy & Mechanism • Security Policy Defines Rules for Authorizing Access to Computer and Resources • Who are Users? What are Resources? What Resources are Available to Each User? Etc… • Protection Mechanisms Authenticate • Access to Resources • Insure File and Memory Protection • A Security Policy is an Organizations Strategy to Authorize Access to the Computer’s Resources • Managers have Access to Personnel Files • OS Processes have Access to the Page Table • Security Transcends OS as a Separate Research and Realization for All Types of Systems/Applications

27. Review Authentication • User/Process Authentication • Is this User/Process Who It Claims to Be? • Passwords • More Sophisticated Mechanisms • Authentication in Networks • Is this Computer Who It Claims to Be? • File Downloading and Transferring • Obtaining Network Services • What is the Java Promise? • What Does Java Guarantee re. Applets? • What Can Application Do that Applet Can’t?

28. Review Authorization • Ability of Principals to Use Machines, Objects, Resources, etc. • Security Policy Defines Capabilities of Each Principal Against Objects, Resources, etc. • Authorization Mechanism Enforces Policy at Runtime • External Authorization • User Attempts to Access Computer • Authenticate Identify and Verify Authorizations • Internal Authorization • Can Process Access a Specific Resource?

29. Review User Authentication • Combination of User ID and Password Universal for Access to Computers • However, Cannot Prevent … • Guessing of Passwords • Stolen and Decrypted Passwords • Masquerading of Intended User • Is User Who they are Supposed to be? • What Extra Information Can User be Asked to Supply? • What About Life Critical Situations (DCP)? • Past Invasion of Engineering Computing • yppasswd File Stolen/Decrypted • S. Demurjian’s Sun Workstation Corrupted

30. ReviewNetwork Authentication • Computers Must Interact with One Another • Classic Example, Transmitting E-Mail Msgs. • Does Transferring Computer have Right to Store a File on Another Computer? • Viruses: Passive Penetrating Entity • Software Module Hidden in Another Module • When Container Executed, Virus Can Penetrate and Wreak Havoc • Worms: Active Penetrating Entity • Actively Seeks to Invade Machine • Morris’s Worm Penetrated via Unix Finger • Passed String that Executed Allocated Memory • Destroyed Runtime Stack/Allowed Worm Execute

31. Review 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

32. Security in Software ApplicationsFocusing on DAC and URBS • Extensive Published Research (Demurjian, et al) in Last Ten Years for DAC/URBS for OO • Efforts in • Automatically Generatable and Reusable Enforcement Mechanisms • MAC/DAC/URBS Security within Distributed Setting • Premise: • Customizable Public Interface of Class • Access to Public Interface is Variable and Based on User Needs and Responsibilities • Only Give Exactly What’s Needed and No More

33. MotivationUser-Role Based Security for OO public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc… For MDs Only For MDs and Nurses For Admitting • Public Interface is Union of All Privileges for All Potential Users No Explicit way to Prohibit Access • Customizable Public Interface of Class • Access to Public Interface is Variable and Based on User Needs and Responsibilities • Only Give Exactly What’s Needed and No More

34. 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 Stressed Exploiting OO/PL Capabilities (Inheritance, Exceptions, Generics) While Limiting SW Engineers Knowledge

35. What are Key Security Concepts? • Assurance • Are the Security Privileges for Each User Adequate to Support their Activities? • Do the Security Privileges for Each User Meet but Not Exceed their Capabilities? • Consistency • Are the Defined Security Privileges for Each User Internally Consistent? • Least-Privilege Principle: Just Enough Access • Are the Defined Security Privileges for Related Users Globally Consistent? • Mutual-Exclusion: Read for Some-Write for Others

36. URBS for OO Systems/Applications • User Role Based Security for Discretionary Access Control • OO Design Model Enhancements • URs, UTs, and UCs • User-Role Definition Hierarchy • Node Profiles for Privileges • URBS Example for SDEs • Security Issues for OO Paradigm • URBS Approaches - OO, ADAM, and C++ • Advanced Security Code Generation • Software Architectures and URBS

37. What is User-Role Based Security(URBS)? • Most OO Programming and Database Languages have a Single Public Interface that is Shared by All Users of OT/Class • Consequently, Public Interface Often Union of all Possible Methods Required by All Likely Users • Discretionary Access Control: • Occurs at Type-Level • Different Portions of Public Interface Available to Different Users at Different Times Depending on User-Roles • Promote Potential Public Interface

38. Motivating Security for OO Paradigm • OO Paradigm Provides Minimal Support via Public Interface and Private Implementation • Public Interface Represents UNION of all Possible Privileges Needed by All Potential Users • A Method in the Public Interface for One Specific User Available to ALL Users • Can Access to Public Interface be Customized? • Can Individuals have Particular Access to Specific Subsets of Public Interface? • Can Access be Based on (Potentially) Dynamic User Roles? • Can Code be Automatically Generated to Implement an Enforcement Mechanism? • Role of OO Paradigm in Support a Generic, Evolvable, Reusable Enforcement Mechanism?

39. Why is URBS Needed? • Many Situations When OT Library Designer (SWE) Could Utilize More Fine-Grained Control to Access of Public Interface • Tradeoff Between Developers and End-Users • SWEs Have Different Roles Based on Their Responsibilities Related to Cooperative Design on an Application • SWEs Should Only See Those Portions of the Application That They Need to See or That They Will Be Responsible for Implementing • End-users Must Be Limited in Their Interactions and Access Depending on Their Roles

40. Why is URBS Needed? • For Example: • In SDEs, the public interface for Modules has methods that read (for SWEs and Managers) and modify instances (only for SWEs) • In HTSS, the public interface for Items has methods that read (for Scanner, I-Controller) and modify instances (only for I-Controller) • In HCA, different health care professionals (e.g., Nurses vs. Physicians vs. Administrators, etc.) require select access to sensitive patient data

41. What is URBS Approach? • Collects User Role, User Type, and User Class into User-Role Definition Hierarchies for Application • To Establish Privileges: Assign Different Methods of PIs to Different UCs, UTs, and URs • Defined Security Must be Enforced: • For SWEs - by Supporting Environment • For End-Users - by Application and Its Tools • URBS Approach Intentionally Obscures Information and Its Access • Consistent with OO Principles on Hiding • Force SWEs to Focus on Abstract Concepts • Incorporate URBS into OO in a Manner Consistent with OO Principles and Philosophy

42. FYI: The ADAM Environment +---------------------------------------------+ | ADAM OO GUI Code Generation | | +----------------+ +---------------+ | | | OO Design and |-------| Ada83, Ada95 | | | | URBS Definition| | C++, Ontos C++| | | +----------------+ | Latex Documen.| | | | | Eiffel, IDL | | | | | ---------| | | +-------------+ | JAVA |Mod-3 | | | | Server | +---------------+ | | | Abstraction | <--- Supports Design | | +-------------+ Persistence | | / | | | / | | | / | | | Unix Ontos Other DBS... | | File OODBS | | System | | ADAM/UNIX, IV3.1, X, SparcStation | | ADAM/PC, Windows95, Borland C++ | | ADAM/NT, WindowsNT, Java | +---------------------------------------------+

43. OO Design Model Enhancements • Extend OO Design Model to Support URBS • Extensions are Consistent with Model and OO Paradigm • Focus on: • User-Role Definition Hierarchy • Identifying Relevant Profiles • Detailing Privilege Acquisition Process • Changes to Existing Profiles • Automatic Analyses for Information Consistency

44. The Health Care Application - OTs

45. The Health Care Application - OTs

46. The Health Care Application - OTs

47. The Health Care Application - RTs

48. The User Role Definition Hierarchy • Characterize Individual/Group Application Access via Hierarchy in Three Abstraction Levels : • User-Roles (URs) for Fine-Grained Activities • grade-recorder (changes and corrections) • transcript-issuer (fill transcript request) • User-Types (UTs) for Similarities that are Shared Among Set of URs • registrar-staff is common responsibilities (access student records) among URs • User-Classes (UCs) for Commonalities Across UTs • non-academic-staff (UTs: purchasing-staff, campus-police, maintenance-staff, etc.) • academic-staff (UTs: dept-staff, registrar-staff, presidents-office, etc.)

49. User Role Definition Hierarchy for HCA Users UC:Medical_Staff UC:Support_Staff Etc. UT:Nurse UT:Physcian UT:Technician UR:Lab UR:Pharmacy UR:Radiology UR:Private UR:Attending UR:Education UR:Staff_RN UR:Director UR:Discharge_Plng UR:Manager

50. User Role Definition Hierarchy for HTSS Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \ \ / \ \.... / \ \ / \ purchasing campus-police ... dept-staff registrar-staff ... / \ ... ... / \ grade-recording transcript-issuing