CSE333 URBSOO-1 User Role Based Security for Object-Oriented Systems/Applications M.-Y. Hu, S. Demurjian, T.C. Ting Computer Science & Engineering Department.

CSE333

URBSOO-1

User Role Based SecurityUser Role Based Securityfor Object-Oriented Systems/Applicationsfor Object-Oriented Systems/Applications

M.-Y. Hu, S. Demurjian, T.C. TingComputer Science & Engineering Department

The University of ConnecticutStorrs, Connecticut 06269-3155

{steve, [email protected]://www.engr.uconn.edu/~steve

(860) 486 - 4818

CSE333

URBSOO-2

Overview of PresentationOverview of Presentation

Object-Oriented Design Model ConceptsObject-Oriented Design Model Concepts Review: Approaches/Concepts of SecurityReview: Approaches/Concepts of Security Motivation of URBS for OOMotivation of URBS for OO User Role Based Security for Discretionary User Role Based Security for Discretionary

Access ControlAccess 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 CommentsReflections and Comments

CSE333

URBSOO-3

An Object-Oriented Design ModelAn Object-Oriented Design Model

Assumptions of OO Design ModelAssumptions of OO Design Model Vocabulary:Vocabulary:

What are Object Types? Attributes? Methods?

Public Interface vs. Hidden ImplementationPublic Interface vs. Hidden Implementation Concept of a ProfileConcept of a Profile Inheritance and its VariantsInheritance and its Variants

CSE333

URBSOO-4

OTs, Attributes, and MethodsOTs, Attributes, and Methods

CSE333

URBSOO-5

Encapsulation and HidingEncapsulation and Hiding

CSE333

URBSOO-6

Profiles to Track Design DataProfiles to Track Design Data

Profiles Contain Detailed Requirements on the Profiles Contain Detailed Requirements on the Semantic Contex(n)t for All Constructs of Semantic Contex(n)t for All Constructs of ApplicationApplication

Force SWEs to Supply Detailed Design Info. As Force SWEs to Supply Detailed Design Info. As Application is DesignedApplication is Designed

All Profiles Share Following: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 ConstructsWe'll Focus on Non-Security Constructs We'll Provide Examples via earlier Prototype We'll Provide Examples via earlier Prototype

(ADAM) and Health Care Application (HCA)(ADAM) and Health Care Application (HCA)

CSE333

URBSOO-7

Attribute ProfileAttribute Profile

CSE333

URBSOO-8

Method ProfileMethod Profile

CSE333

URBSOO-9

Object Type ProfileObject Type Profile

CSE333

URBSOO-10

Object Type ProfileObject Type Profile

CSE333

URBSOO-11

Inheritance VariantsInheritance Variants

Distinguish Between Type and Instance Level Distinguish Between Type and Instance Level Employ a Hierarchy to Define Choices:Employ a Hierarchy to Define Choices:

T-LEVEL: Variants that Dictate the Information and T-LEVEL: Variants that Dictate the Information and Behavior that is Inherited by Subtype from SupertypeBehavior that is Inherited by Subtype from Supertype

I-LEVEL: Variants that Relate to If and How a Subtype is I-LEVEL: Variants that Relate to If and How a Subtype is InstantiatedInstantiated

ISA / +-----+ +---------+ / T-LEVEL I-LEVEL / / | +---+ / +----+ | / / |FULL PRIV1 PRIV2 RESTR CONSTRUCTOR / | +--+ | / | ABSTR LEAF(DB) REGULAR(PL)

CSE333

URBSOO-12

Four T-LEVEL CombinationsFour T-LEVEL Combinations

What Can be Inherited?What Can be Inherited? Who Can See What When?Who Can See What When?

CSE333

URBSOO-13

What Dictates Correct Variant?What Dictates Correct Variant?

The OT's Role in Application: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. ApplicationThe Responsibility SWEs w.r.t. Application A Time Factor which Mandates Different A Time Factor which Mandates Different

Interpretations in a Application's Lifetime: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 DesignTrying to Integrate Security Concepts into Design

CSE333

URBSOO-14

C++ Equivalents for VariantsC++ Equivalents for Variants

To Understand Different Variants, Let's Consider To Understand Different Variants, Let's Consider C++ Analogs for Design Model ConstructsC++ Analogs for Design Model Constructs

Provides a General Indication of Impact of Provides a General Indication of Impact of Different Inheritance Combinations on Code Different Inheritance Combinations on Code GenerationGeneration

CSE333

URBSOO-15

Impact on Code GenerationImpact 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!

CSE333

URBSOO-16


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;

CSE333

URBSOO-17

Three I-LEVEL CombinationsThree I-LEVEL Combinations

ABSTR: Short for Abstract ClassABSTR: Short for Abstract Class Instantiation of a Subtype is Neither Desirable

Nor Possible LEAF: Database VersionLEAF: Database Version

Creation (Deletion) of Instances at the Leaves

REGULAR: Programming VersionREGULAR: Programming Version Creation/Deletion at Any Hierarchy Node Implications on University Example?

Person / / Student Employee / / UnderGrad Graduate Faculty

CSE333

URBSOO-18


No Changes to Previous Slides on What Gets No Changes to Previous Slides on What Gets InheritedInherited

ABSTR: At Least One Pure Abstract MethodABSTR: At Least One Pure Abstract Method LEAF: Instantiate at Leaf NodesLEAF: Instantiate at Leaf Nodes

REGULAR: Generate Public ConstructorsREGULAR: Generate Public Constructors What Happens With Mixed Inheritance Variants?What Happens With Mixed Inheritance Variants? Which Ones Make Sense?Which Ones Make Sense? Which Ones Cause Conflicts?Which Ones Cause Conflicts?

GENERATE protected constructors in C++!

PERSON - constructor is protected | EMPLOYEE - constructor is protected | FACULTY - constructor is public

CSE333

URBSOO-19

C++: (REGULAR, FULL) InheritanceC++: (REGULAR, FULL) Inheritance

CSE333

URBSOO-20

C++: (LEAF, RESTR1) InheritanceC++: (LEAF, RESTR1) Inheritance

class Record : public Object {// ATTRIBUTES:private:int RecNo; // A unique record numberprotected:// 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();;

CSE333

URBSOO-21

Glossary of Protection and Security TermsGlossary of Protection and Security Terms

Access Control ListAccess Control List List of Principals (User, Process, …)

Authorized to have Access to Some Object AuthenticateAuthenticate

Verify Identity of Principal Making Request AuthorizeAuthorize

Grant Principal Access to Information CapabilityCapability

Unforgeable Ticket as Proof of Authorization of Presenter to Access Named Object

Capability ListCapability List List of Protected Objects which Likewise List

Authorized Principles

CSE333

URBSOO-22


CertifyCertify Verify Accuracy, Correctness, & Completeness

of Security/Protection Mechanism ConfinementConfinement

Restricting What a Process Can Do to with Authorized Objects

DomainDomain Objects Currently Accessed by Principal

(De)Encryption(De)Encryption De(Encoding) of Data According to

Transformation Key for Transmission/Storage GrantGrant

Authorize Access to Objects by Principals

CSE333

URBSOO-23


PasswordPassword Encrypted Character String to Authenticate

Identity of Individual PermissionPermission

Form of Allowed Access to Object (R, W, RW) PrincipalPrincipal

Entity (Person/Process/etc.) to Which Authorizations are Granted

PrivacyPrivacy Ability to Decide Whether, When, and to Whom

Information is Released PropagationPropagation

Principal Passing on Authorization to Object to Another Principal

CSE333

URBSOO-24


Protected ObjectProtected Object Known Object whose Internal Structure is

Inaccessible Except by Protection System Protection & SecurityProtection & Security

Mechanisms and Techniques to Control Access to Information by Executing Programs

RevokeRevoke Remove Previously Authorized Access from

Principals Ticket-OrientedTicket-Oriented

Each Principal Maintains List of Unforgeable Tickets Denoting Objects have been Authorized

Glossary from: Saltzer and Schroeder, “The Protection of Information in Glossary from: Saltzer and Schroeder, “The Protection of Information in Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.Computer Systems”, Proc. of IEEE, Vol. 63, No. 9, September 1975.

CSE333

URBSOO-25

ReviewReviewFundamental Security IssuesFundamental Security Issues

Software Engineers Can Write Complex Programs Software Engineers Can Write Complex Programs Limited by Intellectual CapabilitiesLimited by Intellectual Capabilities

OS Designer Must Create Protection Scheme that OS Designer Must Create Protection Scheme that Can’t be Bypassed by Current and Future SoftwareCan’t be Bypassed by Current and Future Software

Users and Processes InitiatorsUsers 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 Protection System of OS Must Support Above

According to Organization’s Admin. PolicyAccording to Organization’s Admin. Policy

CSE333

URBSOO-26

Review Review Policy & MechanismPolicy & Mechanism

Security Policy Defines Rules for Authorizing Security Policy Defines Rules for Authorizing Access to Computer and ResourcesAccess to Computer and Resources Who are Users? What are Resources? What

Resources are Available to Each User? Etc… Protection Mechanisms Authenticate Protection Mechanisms Authenticate

Access to Resources Insure File and Memory Protection

A Security Policy is an Organizations Strategy to A Security Policy is an Organizations Strategy to Authorize Access to the Computer’s ResourcesAuthorize 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 Security Transcends OS as a Separate Research and Realization for All Types of Systems/ApplicationsRealization for All Types of Systems/Applications

CSE333

URBSOO-27

Review Review AuthenticationAuthentication

User/Process AuthenticationUser/Process Authentication Is this User/Process Who It Claims to Be?

Passwords More Sophisticated Mechanisms

Authentication in NetworksAuthentication 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?

CSE333

URBSOO-28

Review Review AuthorizationAuthorization

Ability of Principals to Use Machines, Objects, Ability of Principals to Use Machines, Objects, Resources, etc.Resources, etc.

Security Policy Defines Capabilities of Each Security Policy Defines Capabilities of Each Principal Against Objects, Resources, etc.Principal Against Objects, Resources, etc.

Authorization Mechanism Enforces Policy at Authorization Mechanism Enforces Policy at RuntimeRuntime

External AuthorizationExternal Authorization User Attempts to Access Computer Authenticate Identify and Verify Authorizations

Internal AuthorizationInternal Authorization Can Process Access a Specific Resource?

CSE333

URBSOO-29

Review Review User AuthenticationUser Authentication

Combination of User ID and Password Universal Combination of User ID and Password Universal for Access to Computersfor Access to Computers

However, Cannot Prevent …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 ComputingPast Invasion of Engineering Computing yppasswd File Stolen/Decrypted S. Demurjian’s Sun Workstation Corrupted

CSE333

URBSOO-30

ReviewReviewNetwork AuthenticationNetwork Authentication

Computers Must Interact with One AnotherComputers 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 EntityViruses: Passive Penetrating Entity

Software Module Hidden in Another Module When Container Executed, Virus Can Penetrate

and Wreak Havoc Worms: Active Penetrating EntityWorms: 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

CSE333

URBSOO-31

Review Review What are Available Security Approaches? What are Available Security Approaches?

Mandatory Access Control (MAC)Mandatory Access Control (MAC) Bell/Lapadula Security Model Security Levels for Data Items Access Based on Clearance of User

Discretionary Access Control (DAC)Discretionary Access Control (DAC) Richer Set of Access Modes Focused on Application Needs/Requirements

User-Role Based Security (URBS)User-Role Based Security (URBS) Variant of DAC Responsibilities of Users Guiding Factor Facilitate User Interactions while

Simultaneously Protecting Sensitive Data

CSE333

URBSOO-32

Security in Software ApplicationsSecurity in Software ApplicationsFocusing on DAC and URBSFocusing on DAC and URBS

Extensive Published Research (Demurjian, et al) in Extensive Published Research (Demurjian, et al) in Last Ten Years for DAC/URBS for OOLast Ten Years for DAC/URBS for OO

Efforts in Efforts in Automatically Generatable and Reusable

Enforcement Mechanisms MAC/DAC/URBS Security within Distributed

Setting Premise: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

CSE333

URBSOO-33

MotivationMotivationUser-Role Based Security for OOUser-Role Based Security for OO

Public Interface is Union of All Privileges for All Public Interface is Union of All Privileges for All Potential Users Potential Users No Explicit way to Prohibit AccessNo Explicit way to Prohibit Access

Customizable Public Interface of ClassCustomizable Public Interface of Class Access to Public Interface is Variable and Based Access to Public Interface is Variable and Based

on User Needs and Responsibilitieson User Needs and Responsibilities Only Give Exactly What’s Needed and No More Only Give Exactly What’s Needed and No More

public class PatientRecord { private: Data/Methods as Needed; public: write_medical_history(); write_prescription(); get_medical_history(); get_diagnosis(); set_payment_mode(); etc…

For MDsand Nurses

For MDs Only

For Admitting

CSE333

URBSOO-34

Focusing on DAC and URBSFocusing 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

CSE333

URBSOO-35

What are Key Security Concepts?What are Key Security Concepts?

AssuranceAssurance 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? ConsistencyConsistency

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

CSE333

URBSOO-36

URBS for OO Systems/ApplicationsURBS for OO Systems/Applications

User Role Based Security for Discretionary Access User Role Based Security for Discretionary Access ControlControl

OO Design Model EnhancementsOO Design Model Enhancements URs, UTs, and UCs User-Role Definition Hierarchy Node Profiles for Privileges

URBS Example for SDEsURBS Example for SDEs Security Issues for OO ParadigmSecurity Issues for OO Paradigm URBS Approaches - OO, ADAM, and C++URBS Approaches - OO, ADAM, and C++ Advanced Security Code GenerationAdvanced Security Code Generation Software Architectures and URBSSoftware Architectures and URBS

CSE333

URBSOO-37

What is User-Role Based What is User-Role Based Security(URBS)?Security(URBS)?

Most OO Programming and Database Languages Most OO Programming and Database Languages have a Single Public Interface that is Shared by have a Single Public Interface that is Shared by All Users of OT/ClassAll Users of OT/Class

Consequently, Public Interface Often Union of all Consequently, Public Interface Often Union of all Possible Methods Required by All Likely Users Possible Methods Required by All Likely Users

Discretionary Access Control: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

CSE333

URBSOO-38

Motivating Security for OO ParadigmMotivating Security for OO Paradigm

OO Paradigm Provides Minimal Support via Public OO Paradigm Provides Minimal Support via Public Interface and Private ImplementationInterface and Private Implementation

Public Interface Represents UNION of all Possible Public Interface Represents UNION of all Possible Privileges Needed by All Potential UsersPrivileges Needed by All Potential Users

A Method in the Public Interface for One Specific A Method in the Public Interface for One Specific User Available to ALL UsersUser 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?

CSE333

URBSOO-39

Why is URBS Needed?Why is URBS Needed?

Many Situations When OT Library Designer Many Situations When OT Library Designer (SWE) Could Utilize More Fine-Grained Control (SWE) Could Utilize More Fine-Grained Control to Access of Public Interfaceto Access of Public Interface

Tradeoff Between Developers and End-UsersTradeoff 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

CSE333

URBSOO-40

Why is URBS Needed?Why is URBS Needed?

For Example: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

CSE333

URBSOO-41

What is URBS Approach?What is URBS Approach?

Collects User Role, User Type, and User Class into Collects User Role, User Type, and User Class into User-Role Definition Hierarchies for ApplicationUser-Role Definition Hierarchies for Application

To Establish Privileges: Assign Different Methods To Establish Privileges: Assign Different Methods of PIs to Different UCs, UTs, and URsof PIs to Different UCs, UTs, and URs

Defined Security Must be Enforced:Defined Security Must be Enforced: For SWEs - by Supporting Environment For End-Users - by Application and Its Tools

URBS Approach Intentionally Obscures URBS Approach Intentionally Obscures Information and Its AccessInformation and Its Access Consistent with OO Principles on Hiding Force SWEs to Focus on Abstract Concepts

Incorporate URBS into OO in a Manner Consistent Incorporate URBS into OO in a Manner Consistent with OO Principles and Philosophywith OO Principles and Philosophy

CSE333

URBSOO-42

FYI: The ADAM EnvironmentFYI: 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 |+---------------------------------------------+

CSE333

URBSOO-43

OO Design Model EnhancementsOO Design Model Enhancements

Extend OO Design Model to Support URBS Extend OO Design Model to Support URBS Extensions are Consistent with Model and OO Extensions are Consistent with Model and OO

ParadigmParadigm Focus on:Focus on:

User-Role Definition Hierarchy Identifying Relevant Profiles Detailing Privilege Acquisition Process Changes to Existing Profiles

Automatic Analyses for Information ConsistencyAutomatic Analyses for Information Consistency

CSE333

URBSOO-44

The Health Care Application - OTsThe Health Care Application - OTs

CSE333

URBSOO-45


CSE333

URBSOO-46


CSE333

URBSOO-47

The Health Care Application - RTsThe Health Care Application - RTs

CSE333

URBSOO-48

The User Role Definition HierarchyThe User Role Definition Hierarchy

Characterize Individual/Group Application Access Characterize Individual/Group Application Access via Hierarchy in Three Abstraction Levels :via Hierarchy in Three Abstraction Levels :

User-Roles (URs) for Fine-Grained ActivitiesUser-Roles (URs) for Fine-Grained Activities grade-recorder (changes and corrections) transcript-issuer (fill transcript request)

User-Types (UTs) for Similarities that are Shared User-Types (UTs) for Similarities that are Shared Among Set of URsAmong Set of URs registrar-staff is common responsibilities (access

student records) among URs User-Classes (UCs) for Commonalities Across UTsUser-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.)

CSE333

URBSOO-49

User Role Definition Hierarchy for HCAUser Role Definition Hierarchy for HCA

Users

UC:Medical_Staff

UT:Nurse UT:Physcian

UR:Manager

UR:Staff_RN UR:Education

UR:Discharge_Plng

UR:Private UR:Attending

UC:Support_Staff

Etc.

UT:Technician

UR:Director

UR:Lab UR:Pharmacy

UR:Radiology

CSE333

URBSOO-50

User Role Definition Hierarchy for HTSSUser Role Definition Hierarchy for HTSS

Users / \ +---+ +-----+ / \ non-academic-staff academic-staff / \ \ / \ \.... / \ \ / \ purchasing campus-police ... dept-staff registrar-staff ... / \ ... ... / \ grade-recording transcript-issuing

CSE333

URBSOO-51

Privilege Definition ProcessPrivilege Definition Process

AssignmentAssignment Assign Methods to Various Nodes of URDH Methods that are Assigned are Positive

Privileges Indicate they can be Invoked by User (via a

Software Application/Client) ProhibitionProhibition

Indicate the Methods which Can’t be Called These represent the Negative Privileges Attempt to Invoke by User (via a Software

Application/Client) Results in Exception Why are Prohibited Methods Necessary?Why are Prohibited Methods Necessary?

CSE333

URBSOO-52

Privilege Acquisition ProcessPrivilege Acquisition Process

AssignmentAssignment Assigned to UR for Its Use Only Assigned to UT and Passed to Its URs Assigned to UC and Passed to Its UTs

Employ OO Concepts: Inheritance w.r.t. PrivilegesEmploy OO Concepts: Inheritance w.r.t. Privileges Specialization (UT to URs) Generalization (URs to UT, UTs to UC)

Notes:Notes: A UR Under 2 UTs May Have Diff. Meaning URs Cannot be Further Specialized Granularity of UR: Designer Definable! Vitals, SetIV, etc., in HCA OrderItem, TakeInventory, etc., in HTSS

CSE333

URBSOO-53

Node Profiles and PrivilegesNode Profiles and Privileges

Profiles Contain Detailed Requirements on the Profiles Contain Detailed Requirements on the Semantic Contex(n)t for Security Related Aspects Semantic Contex(n)t for Security Related Aspects of Applicationof Application

CSE333

URBSOO-54

Node DescriptionsNode DescriptionsExamples from HCAExamples from HCA

CSE333

URBSOO-55

Role Security RequirementsRole Security Requirements Examples from HCA Examples from HCA

CSE333

URBSOO-56

Assignment of MethodsAssignment of Methods Positive Privileges for Nodes Positive Privileges for Nodes

Explicit Access to PPI Methods of OTsExplicit Access to PPI Methods of OTs Staff_RN Assigned: Staff_RN Assigned:

Get_Symptom of Visit and Get_Medication of Prescription

Get_Patient_Name of Record and Get_Test of Medical_R

Set_Symptom (record symptoms on patients) Set_Test_Code (record test to be conducted) Set_Patient_Name and Insert_Med_History

Discharge_Plng and Education Assigned:Discharge_Plng and Education Assigned: Similar Get Methods Limited Write: Insert_Med_History

CSE333

URBSOO-57

Implied Methodology for AssignmentImplied Methodology for Assignment

Privileges Associated with URsPrivileges Associated with URs Shared Privileges for URs Under Same UT Can be Shared Privileges for URs Under Same UT Can be

Moved to UTMoved to UT Shared Privileges for UTs Under Same UC Can be Shared Privileges for UTs Under Same UC Can be

Moved to UCMoved to UC However, Methods Assigned to:However, Methods Assigned to:

UC Available to Its UTs/URs UT Available to Its URs

Observe that:Observe that: Commonalities Push Up Tree Differences Flow Down Tree

CSE333

URBSOO-58

Two Important ConceptsTwo Important Concepts

Methods Call Other MethodsMethods Call Other Methods “8” Methods Assigned to Staff_RN

Direct Methods/Explicitly Assigned “n” Indirect Methods Assigned to Staff_RN

“8” Methods Assigned Call Other Methods In Turn, Other Methods Call Still Other Methods Hence, Chaining Effect of Implied (Actual) Calls

Methods on URDH Mirror Inheritance ConceptsMethods on URDH Mirror Inheritance Concepts Methods on UC Available to all of its UR Methods on UR Specific to that Role

CSE333

URBSOO-59

Prohibited MethodsProhibited MethodsNon-Allowed Actions/Negative PrivilegesNon-Allowed Actions/Negative Privileges Important To Give Explicitly, Since:Important To Give Explicitly, Since:

Methods Call Other Methods (MP) Assigned Methods Map to Larger Set Due to

Calls and Inheritance Staff_RN Prohibited: Staff_RN Prohibited:

Set_Treatment of Visit Set_Medication of Prescription Get_All methods from Medical_R

Prohibition w.r.t. Hierarchy:Prohibition w.r.t. Hierarchy: On a UR Implies on Its UT/UC On a UT(UC) Implies on Its URs(UTs)

CSE333

URBSOO-60

Consistency CriteriaConsistency Criteria Relationships Between URDH Nodes Relationships Between URDH Nodes

Equivalence - URDH Nodes Must Have Same Equivalence - URDH Nodes Must Have Same Capabilities per Assigned/Prohibited MethodsCapabilities per Assigned/Prohibited Methods Physical Respiratory Respiratory Occupational Education Discharge_Plng

Subsumption - Ordering Among URDH Nodes Subsumption - Ordering Among URDH Nodes w.r.t. Capabilitiesw.r.t. Capabilities Staff_RN Discharge_Plng Manager Staff_RN

Transitive Closure AppliesTransitive Closure Applies

CSE333

URBSOO-61

A Complete Node ProfileA Complete Node Profile

CSE333

URBSOO-62

The Software Development Environment The Software Development Environment (SDE) Example(SDE) Example

CSE333

URBSOO-63

The SDE URDHThe SDE URDH

UC:SEUC:Manager

CSE333

URBSOO-64

Notation: Extending PPI ConceptsNotation: Extending PPI Concepts

CSE333

URBSOO-65

The SDE URDH with Assigned MethodsThe SDE URDH with Assigned Methods“Lousy” Assignment“Lousy” Assignment

UC:SE {LPI1, M2.3, M3.3}UC:Manager(LPI1)

{LPI4}{LPI2}

{LPI4}{LPI3, M2.1, M2.2}

{M2.4,2.5 M3.4,3.5}

{M2.4,2.5 M3.4,3.5}

{M2.4, M4.1}

Notes: 1-SDECommon, 2-Project, 3-System, 4-Module

CSE333

URBSOO-66

Overview: Assigned MethodsOverview: Assigned Methods

UC SE: LPI1, M2.3, M3.3UC SE: LPI1, M2.3, M3.3 All Methods from SDECommon Retr_System (M2.3) from Project Retr_Module (M3.3) from System All UTs of SE Share Methods

UT SE-Regular: LPI4UT SE-Regular: LPI4 Full Access to all Module Methods Shared by All URs of SE-Regular

UR Report_Bugs: M4.1 Restricted AccessUR Report_Bugs: M4.1 Restricted Access

CSE333

URBSOO-67

Detailed Scope and RationalDetailed Scope and RationalHow are Flaws Identified/Corrected?How are Flaws Identified/Corrected?

CSE333

URBSOO-68

Revising Privileges via URDHRevising Privileges via URDH

Too Much: M-Division UTToo Much: M-Division UT LPI1 (SDECommon) from MANAGER Add_User and Del_User Remove LPI1 from MANAGER Replace with M1.1, M1.4, M1.5, M2.4

Not Enough: SE-Maintain/Document} URNot Enough: SE-Maintain/Document} UR M4.* Methods Not Accessible Not Present on UT or UC Assign Subset of LPI4 M4.1, M4.2, and M4.11

CSE333

URBSOO-69

Revising Privileges via URDHRevising Privileges via URDH

Too Much: SE-Regular/Document URToo Much: SE-Regular/Document UR All Module Methods via LPI4 Includes Modification Methods Move LPI4 Down Hierarchy Assign Subset of LPI4

CSE333

URBSOO-70

Revising Privileges via OTsRevising Privileges via OTs

Which URs Access an OT?Which URs Access an OT? Shouldn't Have: {\tt SDECommon} OTShouldn't Have: {\tt SDECommon} OT

MANAGER/M-Division/Report has Access Realization that Role is Not Needed - Remove SE-Regular has Access to Add_User} and

Del_User Move LPI4 Down Hierarchy to Specific Roles

Should Have: Module OTShould Have: Module OT SE-Maintain/Document} Not On List Correct Oversight as Previously Discussed

Note: Complementary Nature of Analyses w.r.t. Note: Complementary Nature of Analyses w.r.t. URDH vs. OTsURDH vs. OTs

CSE333

URBSOO-71

The SDE URDH with Assigned MethodsThe SDE URDH with Assigned MethodsRevised “Better” AssignmentRevised “Better” Assignment

UC:SE{M1.5,M2.3,M3.3,M4.11}UC:Manager{M1.1,M1.4, M1.5,M2.4}

{LPI4}

{LPI4}{M2.1, {LPI4 M2.2, w/o M3.1, M4.1 M3.2, M4.2} LPI4}

{M1.1, M2.4, M3.4, M4.1}

Notes: 1-SDECommon, 2-Project, 3-System, 4-Module

{M1.4,1.6 M2.4,2.5 M3.4,3.5 M4.1,4.2}

{M1.4,1.6 M2.4,2.5 M3.4,3.5 M4.1,4.2}

{M4.1} {GPI2} {M2.5}

CSE333

URBSOO-72

Last Thoughts on SDE ExampleLast Thoughts on SDE Example

What Actions have Occurred?What Actions have Occurred? Differences Trickle Downward Commonalities Move Upward Too Many/Few Privileges

Possible URDH Changes:Possible URDH Changes: Method Assignments Add a New Role/Delete an Existing Role Split a Role into Two or More Roles

Possible Application Changes:Possible Application Changes: Add/Delete OTs Modify Private Data Items Change Inheritance Add/Modify/Delete Methods

CSE333

URBSOO-73

Security Issues for OO ParadigmSecurity Issues for OO Paradigm

MAC/DAC/URBS - Existing Security ApproachesMAC/DAC/URBS - Existing Security Approaches Must Security for OO Systems Embody an Must Security for OO Systems Embody an

Existing Approach?Existing Approach? Is there a `Better' or `New' Choice to Consider?Is there a `Better' or `New' Choice to Consider? Are there Characteristics/Features of OO Paradigm, Are there Characteristics/Features of OO Paradigm,

Systems, and Applications that Should Dictate Systems, and Applications that Should Dictate Approach?Approach?

Focus on Impact/Influence of:Focus on Impact/Influence of: Encapsulation, Hiding, and Inheritance OO Application Characteristics Polymorphism, Dispatching, Overloading Object-Oriented Paradigm Claim

CSE333

URBSOO-74

Encapsulation, Hiding, and InheritanceEncapsulation, Hiding, and Inheritance

Object Types (OTs)/Classes Involve:Object Types (OTs)/Classes Involve: Encapsulated: Data and Methods Public Interface to Access OT Hidden Implementation Fosters Representation

Independence Encapsulation: Reduces Allowable Actions via the Encapsulation: Reduces Allowable Actions via the

Public Interface Public Interface Hiding: Masks Sensitive Details in ImplementationHiding: Masks Sensitive Details in Implementation Inheritance: Controlled Sharing Among OTs Inheritance: Controlled Sharing Among OTs

Transfers Privileges from Ancestor(s) to Transfers Privileges from Ancestor(s) to Descendant(s)Descendant(s)

All Three Embody Security Concepts!All Three Embody Security Concepts!

CSE333

URBSOO-75

What's in an OO Application?What's in an OO Application?

Application Characteristics:Application Characteristics: High Volumes of Persistent Data Varied/Disparate Data Multiple Individuals/Unique Needs Distributed: Agencies/Individuals/Systems

Public Interface of OT Provides:Public Interface of OT Provides: Methods, Parameters, Return Type One Interface for All Users Can't Control/Limit Access to Public Methods Need: Selective/Customizable Control of Public

Interface Based on an Individual's Role

CSE333

URBSOO-76

What's in an OO Application?What's in an OO Application?

OT/Class Libraries Contain:OT/Class Libraries Contain: Hundreds (or More) OTs Instances/OT Range from Very Few (10s or

Less) to Very Many (1000s or More) Instances Can Change Types Instances/OT Can Change Radically Over Time

Conflicts with MAC: Conflicts with MAC: Relational Data, Few OTs (10s), Many

Instances (1000s) Control at Instance and Attribute Value Levels

CSE333

URBSOO-77

Polymorphism, Dispatching, OverloadingPolymorphism, Dispatching, OverloadingAll Three Embody Security Concepts!All Three Embody Security Concepts!

Polymorphism:Polymorphism: Type-Independent Software Promotes Reuse Realized via Generics or Parameterized Types Can Polymorphism be Used in a Role Independent

Security Library for Authentication and Enforcement? Dispatching:Dispatching:

Run-Time Method Invocation Based on Type Strong Ties to Inheritance, Reuse, and Extensibility Can Dispatching Support Execution of Security Code

by Invoking Different Methods Based on User Roles? Overloading:Overloading:

Methods with Same Name and Different Signatures Ada, C++, SML, etc., Support User-Defined

Overloading Overloading Supports Polymorphism and Dispatching

CSE333

URBSOO-78

Object-Oriented Paradigm ClaimsObject-Oriented Paradigm Claims

Accepted Claims:Accepted Claims: Stresses Modularity Promotes Software Reuse Facilitates Software Evolution

Difficult-to-Prove Claims:Difficult-to-Prove Claims: Controls Data Consistency Increases Productivity

For OO Security, Reuse and Evolution are Critical!For OO Security, Reuse and Evolution are Critical! Both Strongly Linked to Definition and Both Strongly Linked to Definition and

Maintenance of OT/Class LibrariesMaintenance of OT/Class Libraries

CSE333

URBSOO-79

Security Issues and ApproachesSecurity Issues and Approaches

Security Defn./Enforcement Consistent with OO Security Defn./Enforcement Consistent with OO Precepts and PrinciplesPrecepts and Principles

Support for Wide-Variety of User-Roles Support for Wide-Variety of User-Roles User Roles - Extensibility/Evolution CriticalUser Roles - Extensibility/Evolution Critical Target Emerging Systems:Target Emerging Systems:

Focused on OO Systems Supporting C++/Java Programming, SW Engineering, Databases, Security URBS within Joint Object-Oriented Framework Framework Facilitates Development of Application

Code Against Persistent Class Library (and its Underlying DB)

Role-Based Enforcement Mechanism is Part of Executable Image After Compilation

During Runtime, Role of Logged In Individual Utilized to Enforce Security

CSE333

URBSOO-80

Related Work -- All Examine Generated Related Work -- All Examine Generated Code to Realize SecurityCode to Realize Security

Aspects/Richardson and Schwarz - EmergingAspects/Richardson and Schwarz - Emerging Aspects Extend OO Data Models with Roles New Operations/Data Possible for New Roles Our Work has Classes as Superset of

Operations and Data that are Available to Roles Object-Level Control/Richardson, et al.Object-Level Control/Richardson, et al.

Capabilities and ACLs Let Owners of Objects Control Who can Invoke Methods on Instances

Instance Level without Obvious Means to Include User Roles

Subject-Oriented Programming/Harrison & OssherSubject-Oriented Programming/Harrison & Ossher Classes can have Different Subjective Views Very Similar to Our Work

CSE333

URBSOO-81

Core Level URBS Approaches Core Level URBS Approaches

General Solution IssuesGeneral Solution Issues Present Set of Goals for Security:Present Set of Goals for Security:

Extensibility and Flexibility Hiding & Encapsulation Reusability Goals Relevant for both Application and URBS

Enforcement Mechanism Approaches Include:Approaches Include:

Brute-Force User-Role Subclass - Application Perspective URDH Class Library - User Roles Perspective

CSE333

URBSOO-82

General Solution IssuesGeneral Solution Issues

OO Security Designed/Implemented via Libraries OO Security Designed/Implemented via Libraries Geared to Reuse, Extension, and EvolutionGeared to Reuse, Extension, and Evolution

Applications Customize Libraries:Applications Customize Libraries: Generic Libraries Acquire Domain Specifics Libraries Provide Security Definition/Authentication Dynamic Policies: Enforced/Changed Based on Roles Software Tool/Client Application Acquires Security and

Behaves Differently Based on User Roles URBS Enforcement Mechanisms (EM): URBS Enforcement Mechanisms (EM):

URDH and Assigned/Prohibited Methods Brute Force: Method Level Code Changes User-Role Subclassing: Inheritance to Deny Access URDH CLass Library: Inheritance with Both URDH and

Application Utilize C++ (Java Versions Later)

CSE333

URBSOO-83

Goals for URBS Enforcement MechanismGoals for URBS Enforcement Mechanism

Extensibility: Application Perspective:Extensibility: Application Perspective: New Classes, Methods, Roles, etc. Automatic Adjustment by URBS EM?

Extensibility: URBS EM Perspective:Extensibility: URBS EM Perspective: New Security Policies/Approaches Can you go from MAC to DAC?

Flexibility: Application Perspective:Flexibility: Application Perspective: Changes to Roles, Methods, Classes, etc. How does URBS EM Adapt?

Flexibility: URBS EM Perspective:Flexibility: URBS EM Perspective: Change to Security Restrictions/Policy Reimplementation of URBS EM?

CSE333

URBSOO-84


Hiding & Encapsulation: Application Perspective:Hiding & Encapsulation: Application Perspective: Invisible to Users and Components Minimize Impact on Actual Software

Hiding & Encapsulation: URBS EM Perspective:Hiding & Encapsulation: URBS EM Perspective: Representation Independence a Must Exploit OO Paradigm/Principles

Reusability: Application Perspective:Reusability: Application Perspective: Reuse of Classes, Methods, Roles Does URBS EM Always Need Regeneration?

Reusability: URBS EM Perspective:Reusability: URBS EM Perspective: Is URBS EM Application Specific? Is there a Generic URBS EM?

CSE333

URBSOO-85


Software Engineering RelatedSoftware Engineering Related Software Itself

How Pervasive are the Security Additions? Easy to Change/Modify as Privileges Change? Adheres to Existing OOPL Capabilities

Software Engineer How Much Does the Software Engineer Need to

Know about Security? What can be Hidden from Software Engineering? Can we Prevent Software Engineer from Getting at

Restricted Software? For Example, Putting in Trap DoorFor Example, Putting in Trap Door

CSE333

URBSOO-86

Quantifying URBS Approaches Quantifying URBS Approaches

Brute-Force (BFA)Brute-Force (BFA) Focus on Code Level Changes Include “Conditionals” for Each UR Allowed to

Access a Method in Each Methods Code User-Role Subclass (URSA)User-Role Subclass (URSA)

Specify “Subclasses” for Each User Role that Correspond to Each Application Class/OT

Override Prohibited Methods to Return Nulls URDH Class Library (UCLA)URDH Class Library (UCLA)

Employ a Separate Class Library that Mirrors the URDH and Contains Privileges

Requires Casting to Insure Correct Behavior

CSE333

URBSOO-87

Brute Force ApproachBrute Force Approach

Consider HCA Prescription Class:Consider HCA Prescription Class:

UR: Staff_RN Assigned Following MethodsUR: Staff_RN Assigned Following Methods

class Prescription { Public: Set_Prescription_No(....); Get_Prescription_No(....); Set_Pharmacist_Name(....); Get_Pharmacist_Name(....); Set_Medication(....); Get_Medication(....); Protected: char* patient_name, address, ..... }

Get_Prescription_No(....);Get_Pharmacist_Name(....);Get_Medication(....);

CSE333

URBSOO-88

Brute Force ApproachBrute Force Approach

Method Implementation:Method Implementation:

Comments on BFA:Comments on BFA: Code for IFs Easily Generated Any Changes Have Significant Impact Encapsulation is Poor - Spread Across OTs No Identifiable Enforcement Mechanism

char* Prescription::Get_Prescription_No (....) { /* Check if a valid user is accessing the method */ if (User.User_Role == Staff_RN) || (User.User_Role == Physician) || (etc.) { // .... method code for the access ..... } else return (NULL);

CSE333

URBSOO-89

User-Role Subclassing ApproachUser-Role Subclassing Approach

Consider HCA Prescription ClassConsider HCA Prescription Class

Associated Privileges:Associated Privileges:

class Prescription { public: virtual Get_Prescription_No(....); virtual Set_Prescription_No(....); virtual Get_Pharmacist_Name(....); virtual Set_Pharmacist_Name(....); virtual Get_Medication(....); virtual Set_Medication(....); private: char* prescription_no, pharmacist_name, ...}

UR: Attending_MD PM: Set_Pharmacist_Name AMs: All of the Rest

UR: Staff_RN AMs: Get_Pharmacist_Name Get_Prescription_No Get_Medication PMs: Set_Prescription_No Set_Pharmacist_Name Set_Medication

CSE333

URBSOO-90


Generate User-Role Subclasses:Generate User-Role Subclasses:

class Staff_RN_Prescription: public Prescription{ public: virtual void Set_Prescription_No(...) {return;}; virtual void Set_Pharmacist_Name(...) {return;}; virtual void Set_Medication(...) {return;}; };

class Attending_MD_Prescription: public Prescription{ public: virtual void Set_Pharmacist_Name(...) {return;};};

CSE333

URBSOO-91


Behavior at Runtime: Consider the CallBehavior at Runtime: Consider the Call

Type of ptr Determines Which Method is called:Type of ptr Determines Which Method is called:

If Staff_RN User Role, the MethodIf Staff_RN User Role, the Method

is Called Which Returns Nothing (Overridden)is Called Which Returns Nothing (Overridden)

ptr->Set_Prescription_No();

virtual void Set_Prescription_No(...) {return;};

CSE333

URBSOO-92


main() { char user_name[20], user_role[20]; Prescription* P; Staff_RN_Prescription* SP; int Number; char* Medication; cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; // Simulates a URDH and Authorization List Current_User=new User(user_name, user_role); P = new Prescription("Jessica", "3-9-95", 100, "Kitty", "Cold");

CSE333

URBSOO-93


// This is a portion of application code if (strcmp(user_role, "Staff_RN")==0) { // Create a Instance to Hold “Staff_RM” SP = new Staff_RN_Prescription("", "", 0, "", ""); // Copy from the Parent Prescription Object SP->copy_object(P); //copy attributes from parent // Attempt to Invoke a Method as Staff_RN SP->Set_Prescription_No(200); // Set No to 200 //Get the Result of Invocation Number=SP->Get_Prescription_No(); // Staff_RN Doesn’t have Privileges - output 100 cout << "Number==" << Number << "\n"; P->copy_object(SP); //copy attributes from child delete SP; } }

CSE333

URBSOO-94

User-Role Subclassing ApproachUser-Role Subclassing ApproachApplication Code Still UR SpecificApplication Code Still UR Specific

Comments on URSA:Comments on URSA: Extensible via New User-Role Subclasses Hindered by Switch/Recompilation Encapsulation of Security at Method Level Enforcement Mechanism Still Vague

void Fill_Patient_Prescription(..., Prescription* p_rec){ // Determine the role of the user currently switch (User.User_Role()) { case Staff_RN: ((Staff_RN_Prescription *) p_rec)->Set_Prescription_No(...); break; case Attending_MD: ((Attending_MD_Prescription *) p_rec)->Set_Prescription_No(...); break; }}

CSE333

URBSOO-95

URDH Class Library ApproachURDH Class Library Approach

ObjectivesObjectives Utilize Structure of URDH to Record Privileges Track all of Methods Assigned to User Roles,

User Types, and User Classes ResultResult

Class Hierarchy Corresponding to URDH Contains all Permissions Turn Off Permissions at Root Node Turn On Permissions to Correspond to

Assigned Methods Invocation only if Method “Turned On”

CSE333

URBSOO-96

URDH Class Library ApproachURDH Class Library ApproachPartial Class Hierarchy for URDHPartial Class Hierarchy for URDH

Root

Users UC:Medical Staff

UT:Nurse

UR:Staff RNUR:Manager UR:Education

Turn Off All “Check” Methods at Root Node

Turn On Check MethodsTo Correspond toAssigned Methods

Call “Check” Method Prior to Invoking Actual Method

CSE333

URBSOO-97

URDH Class Library ApproachURDH Class Library ApproachURDH ClassesURDH Classes

Consider Following URDH Subset:Consider Following URDH Subset:

and its Corresponding Class Library:and its Corresponding Class Library:

UR: Staff_RN Assigned methods: Get_Prescription_No() (to Staff_RN) Get_Pharmacist_Name() (to Staff_RN) Get_Medication() (to Nurse)

class Root: all methods return False;class Users: public Rootclass Medical_Staff: public Rootclass Nurse: public Users, public Medical_Staff {int Check_Prescription_Get_Medication(){return True;}};class Staff_RN: public Nurse {int Check_Prescription_Get_Prescription_No(){return True;}int Check_Prescription_Get_Pharmacist_Name(){return True;}};

CSE333

URBSOO-98

URDH Class Library ApproachURDH Class Library ApproachImpact on Application ClassesImpact on Application Classes

Introduce “Object” Class to Track Current User Introduce “Object” Class to Track Current User and Tie into URDH Class Hierarchyand Tie into URDH Class Hierarchy

Note User Part of Prescription ConstructorNote User Part of Prescription Constructor

class Object { protected: Root* current_user; ... }

class Item: public Object{ ... }

class Prescription: public Item { public : Prescription(Root* u, char* Name, ...); int Get_Prescription_No(); ... };

CSE333

URBSOO-99

URDH Class Library ApproachURDH Class Library ApproachImpact on Application ClassesImpact on Application Classes

Focus on Actual Method ImplementationsFocus on Actual Method Implementations Wrap Check Method Call Around Method BodyWrap Check Method Call Around Method Body

Note Other Gets and Sets are SimilarNote Other Gets and Sets are Similar

int Prescription::Get_Prescription_No(){ if(current_user-> Check_Prescription_Get_Prescription_No()) return(Prescription_No); else return(NULL);}void Prescription::Set_Prescription_No(int No){ if(current_user-> Check_Prescription_Set_Prescription_No()) {Prescription_No=No;}}

CSE333

URBSOO-100


main() { Prescription* P; char user_name[64]; char user_role[64]; int Number; Root* current_user;

cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; // Create and Simulate a New User if (strcmp(user_role, "Staff_RN") == 0) { current_user = new Staff_RN(user_name); } else current_user = new Root(user_name);

CSE333

URBSOO-101

Key Issues:Key Issues: Create User to Coincide with Entry in URDH

Class Hierarchy and Set Current User Change Each Method Code to Invoke Check

Method Prior to Actual Invocation (Body)


P = new Prescription(current_user,"Jim", "3-9-95", 1, "Ron", "Flu"); // FOLLOWING Set HAS NO EFFECT IF A STAFF_RN // IS ATTEMPTING TO MAKE THE CHANGE P->Set_Prescription_No(100); Number=P->Get_Prescription_No(); cout << "Number==" << Number << "\n"; }

CSE333

URBSOO-102

Comments onComments onURDH Class Library ApproachURDH Class Library Approach

Since Changes aren't Allowed by Unauthorized Since Changes aren't Allowed by Unauthorized Individuals the Need to Undo is EliminatedIndividuals the Need to Undo is Eliminated

Extensibility: As new URs are Changed/Added, Extensibility: As new URs are Changed/Added, Only URDH Class Library Must be RecompiledOnly URDH Class Library Must be Recompiled

Hides Security Code Once a User has been Hides Security Code Once a User has been IdentifiedIdentified

Better Job at Encapsulation of Enforcement Better Job at Encapsulation of Enforcement MechanismMechanism

Still Difficult to Quantify Entire Mechanism as a Still Difficult to Quantify Entire Mechanism as a Single UnitSingle Unit

Steamlines Application CodeSteamlines Application Code Reusability is Definitely Utilized/SuperiorReusability is Definitely Utilized/Superior

CSE333

URBSOO-103

Compare/Contrast the Three ApproachesCompare/Contrast the Three Approaches

Application PerspectiveApplication Perspective

URBS Enforcement Mechanism PerspectiveURBS Enforcement Mechanism Perspective

CSE333

URBSOO-104

Advanced URBS Approaches Advanced URBS Approaches

Generic Security ClassesGeneric Security Classes Streamline Security Defn. Process Achieve Uniformity/Promote Reuse Independent Design/Implementation/Validation

Exception HandlingException Handling Hide Security Code with Handlers Raise Violations when UR Attempts

Unauthorized Access Review Four ApproachesReview Four Approaches

Generic URSA (GURSA) Basic Exception Approach (BEA) Generic Exception Approach (GEA) Advanced Exception Handling

CSE333

URBSOO-105

Generic URSA (GURSA)Generic URSA (GURSA)

Incorporates Generics into URSAIncorporates Generics into URSA Introduce Generic_Prescription TemplateIntroduce Generic_Prescription Template

Parameterized by URType current_UR Pointer Determines Method Called

Based on UR ConceptsConcepts

Each UR Has Own Copy of Prescription Class Cast Based on Role

Review both Template and MainReview both Template and Main Highlight DisadvantagesHighlight Disadvantages

CSE333

URBSOO-106

The Item.h FileThe Item.h File

#ifndef Item_h#define Item_h

class Item {protected: char Physician_Name[64]; char Date[10];

public : Item(char* Name,char* D); char* Get_Physician_Name(); void Set_Physician_Name(char*); char* Get_Date(); void Set_Date(char*);};#endif

CSE333

URBSOO-107

The Prescription.h FileThe Prescription.h File

#ifndef Prescription_h#define Prescription_h#include "item.h"class Prescription: public Item {protected: int Prescription_No; char Pharmacist_Name[64]; char Medication[128];public : Prescription(char* Name,char* D,int No, char* Name1,char* Med); virtual void copy_object(Prescription* P); virtual int Get_Prescription_No(); virtual void Set_Prescription_No(int); virtual char* Get_Pharmacist_Name(); virtual void Set_Pharmacist_Name(char*); virtual char* Get_Medication(); virtual void Set_Medication(char*);};#endif

CSE333

URBSOO-108

The Staff RN Prescription.h File The Staff RN Prescription.h File (s_pres.h)(s_pres.h)

#ifndef Staff_RN_Prescription_h#define Staff_RN_Prescription_h

#include "pres.h"

class Staff_RN_Prescription: public Prescription {public : Staff_RN_Prescription(char* Name,char* D, int No,char* Name1,char* Med): Prescription(Name,D,No,Name1,Med){;} // int Get_Prescription_No(); void Set_Prescription_No(int); // char* Get_Pharmacist_Name(); void Set_Pharmacist_Name(char*); // char* Get_Medication(); void Set_Medication(char*);};#endif

CSE333

URBSOO-109

The Attending MD.h File (a_pres.h)The Attending MD.h File (a_pres.h)

#ifndef Attending_MD_Prescription_h#define Attending_MD_Prescription_h

#include "pres.h"

class Attending_MD_Prescription: public Prescription {public : Attending_MD_Prescription(char* Name,char* D, int No,char* Name1,char* Med): Prescription(Name,D,No,Name1,Med){;} void Set_Pharmacist_Name(char*);};#endif

CSE333

URBSOO-110

Generic_Prescription TemplateGeneric_Prescription Template

#include "s_pres.h" //Staff_RN_Prescription Class#include "a_pres.h" //Attending_MD_Prescription Class

template <class URType> class Generic_Prescription { private: URType *current_UR; public : Generic_Prescription() {current_UR = new URType("", "", 0, "", "");} int Get_Prescription_No() {return(current_UR->Get_Prescription_No());} void Set_Prescription_No(int No) {current_UR->Set_Prescription_No(No);} char* Get_Pharmacist_Name() { ... etc ...} void Set_Pharmacist_Name(char* Name) { ... etc ...} char* Get_Medication() { ... etc ...} void Set_Medication(char* Med) { ... etc ...} void copy_object(Prescription *P) { ... etc ...} };

CSE333

URBSOO-111

The Main Program - GURSAThe Main Program - GURSA

main(){Prescription* P; char user_name[64], char user_role[64], *Medication, *Name; int Number;

cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; P=new Prescription("Jessica","3-9-95”,1,"Kitty","Cold");

if (strcmp(user_role, "Staff_RN")==0) {Generic_Prescription<Staff_RN_Prescription> *SP = new Generic_Prescription<Staff_RN_Prescription>(); SP->copy_object(P); //copy Attributes from the parent SP->Set_Prescription_No(200); // Fails Number=SP->Get_Prescription_No(); // Succeeds cout << "Number==" << Number << "\n"; }

CSE333

URBSOO-112

The Main Program - GURSAThe Main Program - GURSA

else

if (strcmp(user_role, "Attending_MD")==0)

{

Generic_Prescription<Attending_MD_Prescription> *AP

=new Generic_Prescription<Attending_MD_Prescription>();

AP->copy_object(P); //copy attributes from the parent

AP->Set_Prescription_No(200); // Succeeds

AP->Set_Pharmacist_Name("Steve"); // Fails

Number=AP->Get_Prescription_No(); // Succeeds

Name = AP->Get_Pharmacist_Name(); // Succeeds

cout << "Number==" << Number << "\n";

cout << "Name== " << Name << "\n";

}

} // end of main

CSE333

URBSOO-113

Comments on GURSAComments on GURSA

Current UR EncapsulatedCurrent UR Encapsulated Conditional Statement Hinders CodeConditional Statement Hinders Code Extensibility Severely LimitedExtensibility Severely Limited IDevE Must Understand URBSIDevE Must Understand URBS Can Presence of Conditional be Minimize?Can Presence of Conditional be Minimize?

CSE333

URBSOO-114

Minimizing ConditionalMinimizing ConditionalWhat are Problems Here?What are Problems Here?

if (strcmp(user_role, "Staff_RN")==0) Generic_Prescription<Staff_RN_Prescription> *PP =new Generic_Prescription<Staff_RN_Prescription>();else if (strcmp(user_role, "Attending_MD")==0) Generic_Prescription<Attending_MD_Prescription> *PP =new Generic_Prescription<Attending_MD_Prescription>();

// Would allow one block of user-role independent code.PP->copy_object(P); //copy attributes from the parent//Success/Failure of Next Four Callas Based on URPP->Set_Prescription_No(200); PP->Set_Pharmacist_Name("Steve"); Number=PP->Get_Prescription_No(); Name = PP->Get_Pharmacist_Name(); cout << "Number==" << Number << "\n";cout << "Name== " << Name << "\n";

CSE333

URBSOO-115

Basic Exception Approach (BEA)Basic Exception Approach (BEA)

C++ Supports Excepting HandlingC++ Supports Excepting Handling try Encapsulates a Block of Code that has

Potential to Raise Exception throw Used to Raise Exception catch Process Exception

Recast Exception Handling to Support the Raising Recast Exception Handling to Support the Raising Catching, and Processing of Security ViolationsCatching, and Processing of Security Violations

BEA as Follows:BEA as Follows: Extend Class with Exception Handling Methods Capture Assigned/Prohibited Methods in

Runtime Data Structure Allows UR to be Validated via URDH

CSE333

URBSOO-116

Modifications to Prescription ClassModifications to Prescription Class

class Prescription: public Item { // Private data has been omittedpublic: Prescription(char* Name,char* D, int No,char* Name1,char* Med); int Get_Prescription_No(); void Set_Prescription_No(int); char* Get_Pharmacist_Name(); void Set_Pharmacist_Name(char*); char* Get_Medication(); void Set_Medication(char*); // New Methods for Exception Handling int rtn_int_check_valid_UR(int); char* rtn_str_check_valid_UR(char*); void set_int_check_valid_UR(int*,int); void set_str_check_valid_UR(char*,char*); void Check_UR(); // Can UR access method. class Unauthorized_UR { }; };

CSE333

URBSOO-117

Prescription ImplementationPrescription ImplementationPseudo-Code to Illustrate ConceptsPseudo-Code to Illustrate Concepts

int Prescription::Get_Prescription_No() { return(rtn_int_check_valid_UR(Prescription_No));} int Prescription::rtn_int_check_valid_UR(int AInt) { try {// try block has potential to raise exception this->Check_UR(); } // catch block processes any raised exceptions catch (Prescription::Unauthorized_UR) { cout << ”Access by unauthorized UR" << endl; return(INT_NULL); } return(AInt); }

void Prescription::Check_UR() {// Shows invalid URs for Get_Prescription_No method. if ((Current_User->Get_User_Role() != Staff_RN) || (Current_User->Get_User_Role() != Attending_MD)) throw Unauthorized_UR(); // raises exception }

CSE333

URBSOO-118

main() Program for BEAmain() Program for BEA

main(){ Prescription* P; char* Name, Date, Medication, name, role; int Number; char user_name[64], user_role[64];

cout << "Please input your name:"; cin >> user_name; cout << "Please input your role:"; cin >> user_role; Current_User = new User(user_name, user_role); name = Current_User->Get_User_Name() ; role = Current_User->Get_User_Role() ;

CSE333

URBSOO-119

main() Program for BEAmain() Program for BEA

// Data is set as: // MDName, Date, Presc#, PharName, Medication P = new Prescription("Lois", "2-13-96", 1, "John", "Aspirin");

Name = P->Get_Physician_Name(); cout << "Name==" << Name << "\n"; Date = P->Get_Date(); cout << "Date==" << Date << "\n";

// Will fail for UR except Staff_RN or Attending_MD Number = P->Get_Prescription_No(); cout << "Pre_No==" << Number << "\n"; //If fails-Null // Will fail for Staff_RN P->Set_Pharmacist_Name("MeiYu"); // Unchanged if Staff_RN Name = P->Get_Pharmacist_Name(); cout << "Name==" << Name << "\n"; } // end of main

CSE333

URBSOO-120

Comments on BEAComments on BEA

Advantages Include:Advantages Include: Methods rtn, set, Check_UR Encapsulates

URBS Once UR is Set - Conditionals not Needed

(GURSA) Drawbacks Include:Drawbacks Include:

Exception Handling Code Pervasive Extensibility Problem When Changes to

Prescription Replicated Code in set and rtn Reuse not Attained

CSE333

URBSOO-121

Generic Exception Approach (GEA)Generic Exception Approach (GEA)

Extends BEA with GenericsExtends BEA with Generics Alleviates BEA's DisadvantagesAlleviates BEA's Disadvantages Template Class Centralizes Security Violation Template Class Centralizes Security Violation

CodeCode Once Defined, Template Class can be Reused as Once Defined, Template Class can be Reused as

NeededNeeded Core Ideas Include:Core Ideas Include:

rtn, set, prt Methods for Basic Types Ability to Uniquely Identify Classes and

Methods Parameterized by Type of Application Class

CSE333

URBSOO-122

Generic Security TemplateGeneric Security Template

template <class Type> class Gen_Security {protected: int C_ID; // Class ID int M_ID; // Method IDpublic: Gen_Security() {C_ID = M_ID = 0;} void GS_Check_UR(); class Unauthorized_UR { }; // Exception int rtn_int_check_valid_UR(int); float rtn_flt_check_valid_UR(float); char* rtn_str_check_valid_UR(char*); char rtn_chr_check_valid_UR(char); void set_int_check_valid_UR(int*,int); void set_flt_check_valid_UR(float*,float); void set_str_check_valid_UR(char*,char*); void set_chr_check_valid_UR(char,char); void prt_int_check_valid_UR(int); void prt_flt_check_valid_UR(float); void prt_str_check_valid_UR(char*); void prt_chr_check_valid_UR(char);};

CSE333

URBSOO-123

Generic Security ImplementationGeneric Security Implementation

template <class Type> void Gen_Security<Type>::GS_Check_UR() { // Call Check of Owner Class if (Type::Check_UR(C_ID+M_ID) == FAIL) throw Unauthorized_UR(); }

template <class Type> void Gen_Security<Type>::prt_str_check_valid_UR(char* AString) { try {// try block has potential to raise exception this->GS_Check_UR(); }

// catch block processes raised exception catch (Gen_Security::Unauthorized_UR) { cout << "Attempt to access by unauthorized UR" << endl; return; // return control without printing } cout << AString << endl;//output if no exception raised } // WHEN APPLIED TO PRESCRIPTION CLASS GS_CHECK_UR BECOMES:

if (Prescription::Check_UR(C_ID+M_ID) == FAIL) throw Unauthorized_UR();

// THIS VERIFIES IF UR CAN ACCESS METHOD C_ID+M_ID

CSE333

URBSOO-124

The Item Header Class The Item Header Class

#include "gen_security.C"class Item { // Private data has been omittedpublic : Item(char* Name,char* D); char* Get_Physician_Name(); void Set_Physician_Name(char*); void Print_Physician_Name(); char* Get_Date(); void Set_Date(char*); void Print_Date(); // Class specific URBS static int Check_UR(int); // Assigned methods static int Assigned_Methods(int); // Template Declaration Gen_Security<Item> Item_Sec;};

CSE333

URBSOO-125

The Prescription Header ClassThe Prescription Header Class

class Prescription: public Item {//Private data omittedpublic: Prescription(char* Name,char* D, int No,char* Name1,char* Med); int Get_Prescription_No(); void Set_Prescription_No(int); void Print_Prescription_No(); char* Get_Pharmacist_Name(); void Set_Pharmacist_Name(char*); void Print_Pharmacist_Name(); char* Get_Medication(); void Set_Medication(char*); void Print_Medication(); // Class specific URBS static int Check_UR(int); //Assigned methods static int Assigned_Methods(int); //Template declaration Gen_Security<Prescription> Pres_Sec; };

CSE333

URBSOO-126

Prescription ImplementationPrescription Implementation

void Prescription::Print_Pharmacist_Name(){ Pres_Sec.prt_str_check_valid_UR(Pharmacist_Name);} int Item::Check_UR(int unique_method_id){ return(Item::Assigned_Methods(unique_method_id));}

int Prescription::Assigned_Methods(int meth_id){ // For now - simulate by hard-coding response.

if ((strcmp(Current_User->Get_User_Role(), "Staff_RN")==0) ||(strcmp(Current_User->Get_User_Role(), "Attending_MD")==0)) return SUCC;else return FAIL;}

CSE333

URBSOO-127

Comments on GEAComments on GEA

Enhances BEA Advantages via TemplateEnhances BEA Advantages via Template Software Reuse is Strongly promotedSoftware Reuse is Strongly promoted Changes to Prescription/ Item Methods Don't Alter Changes to Prescription/ Item Methods Don't Alter

Method SignaturesMethod Signatures URBS Enforcement is Therefore HiddenURBS Enforcement is Therefore Hidden

CSE333

URBSOO-128

Advanced Exception HandlingAdvanced Exception Handling

Expand BEA and GEA with Advanced Expand BEA and GEA with Advanced CapabilitiesCapabilities

Focus on Added Code to Process Security Focus on Added Code to Process Security ViolationsViolations

Recast Generic Security Template Class with Recast Generic Security Template Class with Multiple ExceptionsMultiple Exceptions

Explore Hypothetical ExamplesExplore Hypothetical Examples

CSE333

URBSOO-129

Revised Generic Security TemplateRevised Generic Security Template

template <class Type> class Gen_Security {protected: int C_ID; // Object ID int M_ID; // Method IDpublic: Gen_Security() {C_ID = M_ID = 0;} void GS_Check_UR();

class Unauthorized_UR { public: int meth_id; Unauthorized_UR(int m_id) { meth_id = m_id; // Remaining code to process exception cout << "Attempt to Access Method --> " << meth_id << endl; cout << "by Unauthorized User Role!!!!" << endl; } }; // End Unauthorized_UR exception Class

CSE333

URBSOO-130


class Logauthorized_UR { public: int meth_id; FILE *f_id; Logauthorized_UR(int m_id) { meth_id = m_id; // Remaining code to process exception // Print message to FILE f_id that logs all // accesses to methods by authorized URs. } }; // End Logauthorized_UR exception Class

// rtn, set, prt methods as given without changes};

CSE333

URBSOO-131


template<class Type> void Gen_Security<Type>::GS_Check_UR(){ // Call Check of Owner Class if (Type::Check_UR(C_ID+M_ID) == FAIL) throw Unauthorized_UR(C_ID+M_ID); else throw Logauthorized_UR(C_ID+M_ID);}

// Two catches needed in relevant Gen_Security methods

catch (Gen_Security::Unauthorized_UR) { cout << "Attempt to access by unauthorized UR" << endl; return; // return control without printing}

catch (Gen_Security::Logauthorized_UR) { cout << "Logging of authorized access by UR" << endl;}

CSE333

URBSOO-132

Compare/Contrast the Four Exception Compare/Contrast the Four Exception Handling Based ApproachesHandling Based Approaches

How do the Four Approaches Compare?How do the Four Approaches Compare? Extensibility Flexibility Hiding/Encapsulation Reusability

Is One Easier than Another?Is One Easier than Another? How do they Rate vs. Earlier Three Approaches?How do they Rate vs. Earlier Three Approaches? What’s Missing in the Process?What’s Missing in the Process?

CSE333

URBSOO-133

Software Architectures for Consistency Software Architectures for Consistency and Assurance of URBS Policiesand Assurance of URBS Policies

MotivationMotivation “How will Assurance and Consistency be

Attained during the Definition and Usage of an application's User-Role Based Security Policy, particularly in an Object-Oriented context that stresses Change and Evolution?”

What is Consistency?What is Consistency? The Ability to Capture and Maintain Inter-Role

and Inter-User Privileges as Changes are Made to the Security Policy over Time

What is Assurance?What is Assurance? The Ability to Guarantee that the Privileges of

each User and Role are Adequate to Satisfy their Respective Functions over Time

CSE333

URBSOO-134

Context and ObjectivesContext and Objectives

Programming Language Role - C++, Ada95, JavaProgramming Language Role - C++, Ada95, Java Security Across Internet/IntranetSecurity Across Internet/Intranet Impact of Application DomainImpact of Application Domain

Health-Care: Life-Critical CAD: Cooperation/Productivity

Promote Security as an Up-Front, Integral Player in Promote Security as an Up-Front, Integral Player in Design and DevelopmentDesign and Development Security Not Just a Database Requirement Cohesive/Comprehensive Sec. Policy Emphasize User Capabilities Equal Partner in Process

CSE333

URBSOO-135

Background and ObjectivesBackground and Objectives

Consistent with OO Precepts and PrinciplesConsistent with OO Precepts and Principles User-Role Based Security: Responsibility FocusUser-Role Based Security: Responsibility Focus Integrate Programming, Software Engineering, Integrate Programming, Software Engineering,

Databases, and SecurityDatabases, and Security Provide a Framework that Facilitates Development Provide a Framework that Facilitates Development

of Application Code Against Persistent Class of Application Code Against Persistent Class Library (and its Underlying DBS)Library (and its Underlying DBS)

During Runtime, Role of Logged In Individual During Runtime, Role of Logged In Individual Utilized to Enforce SecurityUtilized to Enforce Security

Goal: Minimize Amount of Knowledge of Security Goal: Minimize Amount of Knowledge of Security by Software Engineerby Software Engineer

CSE333

URBSOO-136

FocusFocus

Expand Research in Two DimensionsExpand Research in Two Dimensions Consistency and AssuranceConsistency and Assurance

Consistency of Security Policy in a Changing Environment

Assurance of Operation, Security, and Results Instantaneous Availability of ``Correct'' Health

Care Data in Life-Critical Situations Software ArchitecturesSoftware Architectures

URBS at System-Component Level Class Libraries as Building Blocks Alternative Integration Strategies Single and Multi- Process and Processor

Solutions

CSE333

URBSOO-137

Overview Overview

Assurance, Consistency, and AnalysesAssurance, Consistency, and Analyses Software Architectures and URBS Software Architectures and URBS

MechanismsMechanisms Concepts and Definitions Layered Systems Communicating Processes - Client/Server Comparison and Critique

Concluding Remarks on SW ArchitecturesConcluding Remarks on SW Architectures

CSE333

URBSOO-138

Assurance, Consistency, and AnalysesAssurance, Consistency, and Analyses

Who has Responsibility for URBS Policies?Who has Responsibility for URBS Policies? What Tools and Techniques are Needed?What Tools and Techniques are Needed? Design Techniques for:Design Techniques for:

Software & Security Engineers Precisely/Accurately Define Applications Non-Security and URBS Requirements

Suite of Tools for:Suite of Tools for: Design Automatic Analyses of Impact When Changes

Occur to Application or Its Security Policy On-Demand Analyses to Assess State of Design Generation of URBS Enforcement Mechanisms

CSE333

URBSOO-139

Consistency for User-RolesConsistency for User-Roles URs for OO Systems are Dynamic URs for OO Systems are Dynamic

Extension/Evolution of OO Systems is NormExtension/Evolution of OO Systems is Norm Consistency of User RolesConsistency of User Roles

New UR: Internal Consistency Modify UR: Intra-Role Consistency Between URs: Inter-Role Consistency Among URs: Intra-Hierarchy Consistency

Adhere to Two PrinciplesAdhere to Two Principles Least-Privilege: Necessary Privileges and No

More for a UR Mutual-Exclusion: Careful Definition of Can

vs. Can't w.r.t. Privileges for URs Analyses to Assess Attainment of Consistency and Analyses to Assess Attainment of Consistency and

PrinciplesPrinciples

CSE333

URBSOO-140

Consistency for End User AuthorizationsConsistency for End User Authorizations URs for OO Systems are Dynamic URs for OO Systems are Dynamic

Trade off of End-users BehaviorTrade off of End-users Behavior Play Exactly One Role at Some Time Play Multiple Roles Concurrently at Some Time

End-User ConsistencyEnd-User Consistency Relation of User to other Users Based on UR

This is Inter-User Consistency by Role If User Can Play Multiple Roles Must Consider

Dependencies Among Simultaneous Roles This is Intra-User Consistency by Role

Analyses to Assess Attainment of Consistency and Analyses to Assess Attainment of Consistency and PrinciplesPrinciples

CSE333

URBSOO-141

Concepts and DefinitionsConcepts and Definitions

OO Assumptions: Shared Class LibraryOO Assumptions: Shared Class Library Tools Designed Against Class Library End-Users Access Application via Tools Security Policy Enforced via Tools

Different Class LibrariesDifferent Class Libraries AppCL: Shared Application Class Lib. SCL: Security Class Lib. with URBS Defn. and

Enforcement TCL: Tool Class Lib., e.g., a patient GUI

Software ArchitecturesSoftware Architectures Explore Variants for OO and URBS Layered Systems Communicating Processes

CSE333

URBSOO-142

Layered System Version 1Layered System Version 1LS1: Application-Based ApproachLS1: Application-Based Approach

Security at Level of Method InvocationSecurity at Level of Method Invocation Processed by SCL Prior to Access Against Instance Processed by SCL Prior to Access Against Instance

in ACLin ACL

Security Managed at Application LevelSecurity Managed at Application Level All Requests Pass Through Shared SCLAll Requests Pass Through Shared SCL Once SCL OKs, Passed Through to ACLOnce SCL OKs, Passed Through to ACL

CSE333

URBSOO-143

Layered System Version 2Layered System Version 2LS2: Class-Based ApproachLS2: Class-Based Approach

Like LS1, Security at Level of Method InvocationLike LS1, Security at Level of Method Invocation Processed by SCL Prior to Access Against Instance Processed by SCL Prior to Access Against Instance

in ACLin ACL

Security Managed at Instance LevelSecurity Managed at Instance Level Tools Must Interact with Multiple SC/AppC PairsTools Must Interact with Multiple SC/AppC Pairs Sec. Policy and Application DistributedSec. Policy and Application Distributed Problem if Instances Refer to Non-Local InstancesProblem if Instances Refer to Non-Local Instances

CSE333

URBSOO-144

Communicating Processes Version 1Communicating Processes Version 1CP1: Single Process, Base Case, no C/SCP1: Single Process, Base Case, no C/S

Similar to LS1 - Each Similar to LS1 - Each Tool Standalone ProcessTool Standalone Process

SCL and AppCL SCL and AppCL Analogous to Math Analogous to Math LibraryLibrary

SCL Filter between SCL Filter between TCLi and AppCLTCLi and AppCL

SCL/AppCL Partially SCL/AppCL Partially Replicated/DistributedReplicated/Distributed

Changes to SCL/AppCL Changes to SCL/AppCL Impact Multiple ToolsImpact Multiple Tools

Unclear How Unclear How Sharing/DB SupportedSharing/DB Supported

CSE333

URBSOO-145

Communicating Processes Version 2Communicating Processes Version 2CP2: Multi-Process/Shared AppCLCP2: Multi-Process/Shared AppCL

AppCL Separated into AppCL Separated into Own ProcessOwn Process

SCL Still only Subset SCL Still only Subset Needed by TCLiNeeded by TCLi

Like CP1, SCL Like CP1, SCL Changes Impact Changes Impact Multiple TCLsMultiple TCLs

Less Impact for Less Impact for Changes to AppCLChanges to AppCL

Unlike CP1, Database Unlike CP1, Database Integration SupportedIntegration Supported

CSE333

URBSOO-146

Communicating Processes Version 3Communicating Processes Version 3CP3: Multi Process/Shared SCL/AppCLCP3: Multi Process/Shared SCL/AppCL

SCL has Entire SCL has Entire Security PolicySecurity Policy

Changes to Changes to SCL/AppCL SCL/AppCL Shouldn't Impact Shouldn't Impact TCLsTCLs

SCL/AppCL SCL/AppCL Potential Potential Performance Performance BottleneckBottleneck

Particularly with Particularly with Database IntegrationDatabase Integration

CSE333

URBSOO-147

Communicating Processes Version 4Communicating Processes Version 4CP4: C/S, Replctd SCL/Shared AppCLCP4: C/S, Replctd SCL/Shared AppCL

Independence of TCLs (CP2)Independence of TCLs (CP2) Alleviate Performance Alleviate Performance

Problems of CP3Problems of CP3

Replicated/Entire SCLReplicated/Entire SCL Facilitates Database Facilitates Database

System Incorporation System Incorporation

CSE333

URBSOO-148

Comparison of VariantsComparison of Variants

CSE333

URBSOO-149

Critique of VariantsCritique of VariantsSummary/Assessment of 6 VariantsSummary/Assessment of 6 Variants

Consistency/Assurance of Security PolicyConsistency/Assurance of Security Policy Impact when Security Policy EvolvesImpact when Security Policy Evolves Support for PersistencySupport for Persistency

CSE333

URBSOO-150

Concluding Remarks on SW ArchitecturesConcluding Remarks on SW Architectures

Consistency and Assurance for OO Systems Must Consistency and Assurance for OO Systems Must Be an Equal Partner in Design ProcessBe an Equal Partner in Design Process Consider Evolution of Application and Its

Security Policy Explore Solutions that Transcend Traditional

Approaches Software Architectures OfferSoftware Architectures Offer

Componentwise Conceptualization and Realization

Variants LS1, CP3, and CP4 which are Comparable in Pros and Cons

CP4 which More Easily Supports Evolution to Include OODBS

CSE333 URBSOO-1 User Role Based Security for Object-Oriented Systems/Applications M.-Y. Hu, S. Demurjian, T.C. Ting Computer Science & Engineering Department.

Documents

cse333 urbsoo

design slide

comments slide

attribute profile slide

method profile slide

code generation slide

object type profile

design model constructs