Security
CSE
5810
Prof. Steven A. Demurjian, Sr.
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-1155
Storrs, CT 06269-1155
steve@engr.uconn.edu
http://www.engr.uconn.edu/~steve
(860) 486 - 4818

The majority of these slides represent material that has been accumulated
from various sources over the years.
Security-1
Motivation: Security Issues?
Patients
CSE
5810
Patient GUI
Providers
for RN vs. MD
XML
https
https
html
Web Server
Encryption
Firewall
Appl Server
Web - Control Services
Clinical
Researchers
Appl. – Control Methods
Encryption
Secure Communication
Web Content
DB Server
Encryption
GUI Look and Feel
Security-2
Security Issues for Patients
Patients
Providers
CSE
5810




Web-Based
Portal(XML + HL7)
Open Source XML DB
HIPPA Overriding Concern
All Patient Interfaces Web-Based
Secure Communication
 To/From Web Server (https)
 Among Discussion Group Members
Is this https or Peer-to-Peer?
Role-Based Access Control to Authorize
 Providers to Interact
 PHR Data to Individual Providers
Clinical
Researchers
Security-3
Security Issues for Providers
Providers
Patients
EMR
CSE
5810
Web-Based
Portal(XML + HL7)
Open Source XML DB
Clinical
Researchers


HIPPA Concerns for any EMR Data
Transmitted into Portal
Need to Consider Delegation
 Provider P Access to Portal for
Patient X
 Provider Q on Call
 Can P Delegate his Permission to
Access Portal to Q?
 Will Q’s Role (e.g., EMT) Limit
Access Even with Delegation?
Security-4
Security Issues for Clinical Researchers
Patients
CSE
5810
Providers
Web-Based
Portal(XML + HL7)
Open Source XML DB


Clinical Researchers

Feedback Repository
Is Role-Based Access Control Needed to
Authorized Providers to Portal Features?
Security for Discussion Forums?
 Collaborative Interactions Among
Providers and Clinical Researchers
 Is Security Required?
Collect Results from Providers (HIPPA)
 Store in Feedback Repository
 Transfer to Permanent Warehouse
Security-5
Overview

CSE
5810


Explore Wide Range of Security Topics in this and
Associated PPTs:
 Security for Collaborative Web Portals
 Secure Information Exchange via XML
 Object-Oriented/Programmatic Security
 Secure Software Engineering
 Security for Services-Based Computing
Objective – Understand the Wide Range and Location
of Security Across Macro-Architecture
Note: All of these Security Approaches Must work
with the Security Discussed in Background PPTs
Security-6
Our Multi-Pronged Security Emphasis
CSE
5810
User-Role Based Security
in an Object-Oriented
Design Model – Generate
C++/Java Code
Secure MAC/RBAC DAC
Interactions via
Middleware in Distributed
Setting – CORBA and JINI
Secure Software Engineering via
UML to Design and Write Secure
Software Programs
Extending UML and AOP
Integrated Secure-Software
Engineering Approach for
Functional, Collaborative,
and information Concerns
Assurance
Consistency
Integrity
Safety
Liveness
Secure Information
Exchange via XML with
RBAC, DAC, & MAC with
XACML Policy Generation
Collaboration and
Workflow Extensions to NIST
RBAC with Generated Java
Meta-Programming Code
Collaborative Portals
Look-and-Feel Application
Content Document Access
Security-7
PhD Research

CSE
5810
Six Graduated Students over Last 20+ years
 M.-Y. Hu, “Definition, Analyses, and Enforcement of
User-Role Based Security in an Object-Oriented Design
Model” 1993
 C. Phillips, “Security Assurance for a Resource-Based
RBAC/DAC/MAC Security Model,” 2004
 T. Doan, “A Framework for Software Security in UML
with Assurance,” 2008
 J. Pavlich-Mariscal. “A Framework of Composable
Security Features: Preserving Separation of Security
Concerns from Models to Code,” 2008
 S. Berhe, “A Framework for Secure, Obligated,
Coordinated and Dynamic Collaboration that Extends NIST
RBAC,” 2011
 A. De La Rosa Algarin, “An XML Security Framework
that Integrates NIST RBAC, MAC and DAC Policies”,
2014
Security-8
Security for Object-Oriented Settings
M.-Y. Hu
CSE
5810
Definition, Analyses, and Enforcement of
User-Role Based Security in an
Object-Oriented Design Model
H. Ellis
An Information Engineering Approach
to Object-Oriented Design and Analyses
Security-9
Motivating Security for OO Paradigm

CSE
5810


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?
Security-10
Why is RBAC Needed?

CSE
5810

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
Security-11
Why is RBAC Needed?

CSE
5810
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
Security-12
What is RBAC Approach?

CSE
5810




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
RBAC Approach Intentionally Obscures Information
and Its Access
 Consistent with OO Principles on Hiding
 Force SWEs to Focus on Abstract Concepts
Incorporate RBAC into OO in a Manner Consistent
with OO Principles and Philosophy
Security-13
The Health Care Application - OTs
CSE
5810
Security-14
The Health Care Application - OTs
CSE
5810
Security-15
The Health Care Application - OTs
CSE
5810
Security-16
The Health Care Application - RTs
CSE
5810
Security-17
User Role Definition Hierarchy (URDH)

CSE
5810



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.)
Security-18
URDH for HCA
CSE
5810
Users
UC:Medical_Staff
UC:Support_Staff
Etc.
UT:Nurse
UT:Physcian
UT:Technician
UR:Lab
UR:Pharmacy
UR:Radiology
UR:Staff_RN
UR:Education
UR:Private
UR:Attending
UR:Director
UR:Manager
UR:Discharge_Plng
Security-19
Privilege Definition Process

CSE
5810


Assignment
 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)
Prohibition
 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?
Security-20
Privilege Acquisition Process

CSE
5810


Assignment
 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. Privileges
 Specialization (UT to URs)
 Generalization (URs to UT, UTs to UC)
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
Security-21
Node Profiles and Privileges

CSE
5810

Profiles Contain Detailed Requirements on the
Semantic Contex(n)t for Security Related Aspects of
Application
Each Node in the URDH Represented by:
 Name
 Prose Description of Responsibility
 Prose Security Requirement
 Assigned Methods (Positive Privileges)
 Prohibited Methods (Negative Privileges)
 Consistency Criteria (Relations Among Nodes)
Security-22
Node Descriptions - Examples from HCA
CSE
5810
Security-23
Role Security Requirements from HCA
CSE
5810
Security-24
Positive Privileges for Nodes

CSE
5810

Explicit Access to PPI Methods of OTs
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:
 Similar Get Methods
 Limited Write: Insert_Med_History
Security-25
Implied Methodology for Assignment

CSE
5810




Privileges Associated with URs
Shared Privileges for URs Under Same UT Can be
Moved to UT
Shared Privileges for UTs Under Same UC Can be
Moved to UC
However, Methods Assigned to:
 UC Available to Its UTs/URs
 UT Available to Its URs
Observe that:
 Commonalities Push Up Tree
 Differences Flow Down Tree
Security-26
Two Important Concepts

CSE
5810
Methods 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 Concepts
 Methods on UC Available to all of its UR
 Methods on UR Specific to that Role
Security-27
Prohibited Methods - Negative Privileges

CSE
5810


Important To Give Explicitly, Since:
 Methods Call Other Methods (MP)
 Assigned Methods Map to Larger Set Due to Calls
and Inheritance
Staff_RN Prohibited:
 Set_Treatment of Visit
 Set_Medication of Prescription
 Get_All methods from Medical_R
Prohibition w.r.t. Hierarchy:
 On a UR Implies on Its UT/UC
 On a UT(UC) Implies on Its URs(UTs)
Security-28
Consistency Criteria Between URDH Nodes

CSE
5810


Equivalence - URDH Nodes Must Have Same
Capabilities per Assigned/Prohibited Methods
 Physical  Respiratory
 Respiratory  Occupational
 Education  Discharge_Plng
Subsumption - Ordering Among URDH Nodes w.r.t.
Capabilities
 Staff_RN  Discharge_Plng
 Manager  Staff_RN
Transitive Closure Applies
Security-29
A Complete Node Profile
CSE
5810
Security-30
Security Issues for OO Paradigm

CSE
5810




MAC/DAC/RBAC - Existing Security Approaches
Must Security for OO Systems Embody an Existing
Approach?
Is there a `Better' or `New' Choice to Consider?
Are there Characteristics/Features of OO Paradigm,
Systems, and Applications that Should Dictate
Approach?
Focus on Impact/Influence of:
 Encapsulation, Hiding, and Inheritance
 OO Application Characteristics
 Polymorphism, Dispatching, Overloading
 Object-Oriented Paradigm Claim
Security-31
Encapsulation, Hiding, and Inheritance

CSE
5810




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
Public Interface
Hiding: Masks Sensitive Details in Implementation
Inheritance: Controlled Sharing Among OTs Transfers
Privileges from Ancestor(s) to Descendant(s)
All Three Embody Security Concepts!
Security-32
What's in an OO Application?

CSE
5810

Application Characteristics:
 High Volumes of Persistent Data
 Varied/Disparate Data
 Multiple Individuals/Unique Needs
 Distributed: Agencies/Individuals/Systems
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
Security-33
What's in an OO Application?

CSE
5810

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:
 Relational Data, Few OTs (10s), Many Instances
(1000s)
 Control at Instance and Attribute Value Levels
Security-34
Polymorphism, Dispatching, Overloading

CSE
5810
Polymorphism:




Dispatching:




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?
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:



Methods with Same Name and Different Signatures
Ada, C++, SML, etc., Support User-Defined Overloading
Overloading Supports Polymorphism and Dispatching
Security-35
Object-Oriented Paradigm Claims

CSE
5810



Accepted Claims:
 Stresses Modularity
 Promotes Software Reuse
 Facilitates Software Evolution
Difficult-to-Prove Claims:
 Controls Data Consistency
 Increases Productivity
For OO Security, Reuse and Evolution are Critical!
Both Strongly Linked to Definition and Maintenance
of OT/Class Libraries
Security-36
Security Issues and Approaches

CSE
5810



Security Defn./Enforcement Consistent with OO
Precepts and Principles
Support for Wide-Variety of User-Roles
User Roles - Extensibility/Evolution Critical
Target OO Applications and Systems:





Programming, SW Engineering, Databases, Security
RBAC 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
Security-37
Goals for RBAC Enforcement Mechanism

CSE
5810



Extensibility: Application Perspective:
 New Classes, Methods, Roles, etc.
 Automatic Adjustment by RBAC EM?
Extensibility: RBAC EM Perspective:
 New Security Policies/Approaches
 Can you go from MAC to DAC?
Flexibility: Application Perspective:
 Changes to Roles, Methods, Classes, etc.
 How does RBAC EM Adapt?
Flexibility: RBAC EM Perspective:
 Change to Security Restrictions/Policy
 Reimplementation of RBAC EM?
Security-38
Goals for RBAC Enforcement Mechanism

CSE
5810



Hiding & Encapsulation: Application Perspective:
 Invisible to Users and Components
 Minimize Impact on Actual Software
Hiding & Encapsulation: RBAC EM Perspective:
 Representation Independence a Must
 Exploit OO Paradigm/Principles
Reusability: Application Perspective:
 Reuse of Classes, Methods, Roles
 Does RBAC EM Always Need Regeneration?
Reusability: RBAC EM Perspective:
 Is RBAC EM Application Specific?
 Is there a Generic RBAC EM?
Security-39
Goals for RBAC Enforcement Mechanism

CSE
5810
Software 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 Door
Security-40
Quantifying RBAC Approaches

CSE
5810


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)
 Specify “Subclasses” for Each User Role that
Correspond to Each Application Class/OT
 Override Prohibited Methods to Return Nulls
URDH Class Library (UCLA)
 Employ a Separate Class Library that Mirrors the
URDH and Contains Privileges
 Requires Casting to Insure Correct Behavior
Security-41
Brute Force Approach

Consider HCA Prescription Class:
CSE
5810

class Prescription {
Public:
Set_Prescription_No(....);
Get_Prescription_No(....);
Set_Pharmacist_Name(....);
Get_Pharmacist_Name(....);
Set_Medication(....);
Get_Medication(....);
Protected:
char* patient_name, address, .....
}
UR: Staff_RN Assigned Following Methods
Get_Prescription_No(....);
Get_Pharmacist_Name(....);
Get_Medication(....);
Security-42
Brute Force Approach

CSE
5810
Method Implementation:
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);

Comments on BFA:
 Code for IFs Easily Generated
 Any Changes Have Significant Impact
 Encapsulation is Poor - Spread Across OTs
 No Identifiable Enforcement Mechanism
Security-43
User-Role Subclassing Approach

CSE
5810

Consider HCA Prescription Class
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, ...
}
Associated Privileges:
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
Security-44
User-Role Subclassing Approach

Generate User-Role Subclasses:
CSE
5810
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;};
};
Security-45
User-Role Subclassing Approach

Behavior at Runtime: Consider the Call
CSE
5810
ptr->Set_Prescription_No();

Type of ptr Determines Which Method is called:

If Staff_RN User Role, the Method
virtual void Set_Prescription_No(...) {return;};

is Called Which Returns Nothing (Overridden)
Security-46
User-Role Subclassing Approach
CSE
5810
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");
Security-47
User-Role Subclassing Approach
CSE
5810
// 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;
}
}
Security-48
Application Code Still UR Specific
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;
}
}
CSE
5810

Comments on URSA:
 Extensible via New User-Role Subclasses
 Hindered by Switch/Recompilation
 Encapsulation of Security at Method Level
 Enforcement Mechanism Still Vague
Security-49
URDH Class Library Approach

CSE
5810

Objectives
 Utilize Structure of URDH to Record Privileges
 Track all of Methods Assigned to User Roles, User
Types, and User Classes
Result
 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”
Security-50
Partial Class Hierarchy for URDH
CSE
5810
Turn Off All “Check” Methods at Root Node
Root
Users
UR:Manager
UC:Medical Staff
UT:Nurse
Turn On Check Methods
To Correspond to
Assigned Methods
UR:Staff RN
UR:Education
Call “Check” Method Prior to Invoking Actual Method
Security-51
URDH Classes

CSE
5810
Consider Following URDH Subset:
UR: Staff_RN Assigned methods:
Get_Prescription_No() (to Staff_RN)
Get_Pharmacist_Name() (to Staff_RN)
Get_Medication()
(to Nurse)

and its Corresponding Class Library:
class Root: all methods return False;
class Users: public Root
class Medical_Staff: public Root
class 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;}
};
Security-52
Impact on Application Classes

CSE
5810
Introduce “Object” Class to Track Current User and
Tie into URDH Class Hierarchy
class Object {
protected:
Root* current_user;
... }
class Item: public Object{
... }
class Prescription: public Item {
public :
Prescription(Root* u, char* Name, ...);
int Get_Prescription_No();
... };

Note User Part of Prescription Constructor
Security-53
Impact on Application Classes

CSE
5810

Focus on Actual Method Implementations
Wrap Check Method Call Around Method Body
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;}
}

Note Other Gets and Sets are Similar
Security-54
URDH Class Library Approach
CSE
5810
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);
Security-55
URDH Class Library Approach
P = new Prescription(current_user,"Jim",
"3-9-95", 1, "Ron", "Flu");
CSE
5810
// 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";
}

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)
Security-56
Comments: URDH Class Library Approach

CSE
5810






Since Changes aren't Allowed by Unauthorized
Individuals the Need to Undo is Eliminated
Extensibility: As new URs are Changed/Added, Only
URDH Class Library Must be Recompiled
Hides Security Code Once a User has been Identified
Better Job at Encapsulation of Enforcement
Mechanism
Still Difficult to Quantify Entire Mechanism as a
Single Unit
Steamlines Application Code
Reusability is Definitely Utilized/Superior
Security-57
Compare/Contrast the Three Approaches

Application Perspective

RBAC Enforcement Mechanism Perspective
CSE
5810
Security-58
Advanced RBAC Approaches

CSE
5810


Generic Security Classes
 Streamline Security Defn. Process
 Achieve Uniformity/Promote Reuse
 Independent Design/Implementation/Validation
Exception Handling
 Hide Security Code with Handlers
 Raise Violations when UR Attempts Unauthorized
Access
Review Four Approaches
 Generic URSA (GURSA)
 Basic Exception Approach (BEA)
 Generic Exception Approach (GEA)
 Advanced Exception Handling
 See Papers on Course Web Page…
Security-59
Advanced URBS Approaches

CSE5810


Generic Security Classes
 Streamline Security Defn. Process
 Achieve Uniformity/Promote Reuse
 Independent Design/Implementation/Validation
Exception Handling
 Hide Security Code with Handlers
 Raise Violations when UR Attempts
Unauthorized Access
Review Four Approaches
 Generic URSA (GURSA)
 Basic Exception Approach (BEA)
 Generic Exception Approach (GEA)
 Advanced Exception Handling
URBSOO-60
Generic URSA (GURSA)

CSE5810 



Incorporates Generics into URSA
Introduce Generic_Prescription Template
 Parameterized by URType
 current_UR Pointer Determines Method Called
Based on UR
Concepts
 Each UR Has Own Copy of Prescription Class
 Cast Based on Role
Review both Template and Main
Highlight Disadvantages
URBSOO-61
The Item.h File
#ifndef Item_h
CSE5810 #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
URBSOO-62
The Prescription.h File
#ifndef Prescription_h
#define Prescription_h
CSE5810 #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
URBSOO-63
The Staff RN Prescription.h File
(s_pres.h)
#ifndef Staff_RN_Prescription_h
#define Staff_RN_Prescription_h
CSE5810
#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
URBSOO-64
The Attending MD.h File (a_pres.h)
CSE5810
#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
URBSOO-65
Generic_Prescription Template
#include "s_pres.h" //Staff_RN_Prescription Class
#include "a_pres.h" //Attending_MD_Prescription Class
CSE5810
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 ...}
};
URBSOO-66
The Main Program - GURSA
main()
CSE5810 {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";
}
URBSOO-67
The Main Program - GURSA
CSE5810
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
URBSOO-68
Comments on GURSA

CSE5810 



Current UR Encapsulated
Conditional Statement Hinders Code
Extensibility Severely Limited
IDevE Must Understand URBS
Can Presence of Conditional be Minimize?
URBSOO-69
Minimizing Conditional
What are Problems Here?
if (strcmp(user_role, "Staff_RN")==0)
CSE5810
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 UR
PP->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";
URBSOO-70
Basic Exception Approach (BEA)

CSE5810


C++ 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
Catching, and Processing of Security Violations
BEA as Follows:
 Extend Class with Exception Handling Methods
 Capture Assigned/Prohibited Methods in
Runtime Data Structure
 Allows UR to be Validated via URDH
URBSOO-71
Modifications to Prescription Class
CSE5810
class Prescription: public Item {
// Private data has been omitted
public:
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 { };
};
URBSOO-72
Prescription Implementation
Pseudo-Code to Illustrate Concepts
CSE5810
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
}
URBSOO-73
main() Program for BEA
main()
CSE5810 { 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() ;
URBSOO-74
main() Program for BEA
CSE5810
// Data is set as:
//
MDName, Date, Presc#, PharName, Medication
P = new Prescription("Lois", "2-13-96",
1, "John", "Aspirin");
Name
cout
Date
cout
= P->Get_Physician_Name();
<< "Name==" << Name << "\n";
= P->Get_Date();
<< "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
URBSOO-75
Comments on BEA

CSE5810

Advantages Include:
 Methods rtn, set, Check_UR Encapsulates
URBS
 Once UR is Set - Conditionals not Needed
(GURSA)
Drawbacks Include:
 Exception Handling Code Pervasive
 Extensibility Problem When Changes to
Prescription
 Replicated Code in set and rtn
 Reuse not Attained
URBSOO-76
Generic Exception Approach (GEA)

CSE5810 



Extends BEA with Generics
Alleviates BEA's Disadvantages
Template Class Centralizes Security Violation
Code
Once Defined, Template Class can be Reused as
Needed
Core Ideas Include:
 rtn, set, prt Methods for Basic Types
 Ability to Uniquely Identify Classes and
Methods
 Parameterized by Type of Application Class
URBSOO-77
Generic Security Template
CSE5810
template <class Type> class Gen_Security {
protected:
int C_ID; // Class ID
int M_ID; // Method ID
public:
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);
};
URBSOO-78
Generic Security Implementation
CSE5810
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
URBSOO-79
The Item Header Class
#include "gen_security.C"
CSE5810 class Item { // Private data has been omitted
public :
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;
};
URBSOO-80
The Prescription Header Class
class Prescription: public Item {//Private data omitted
public:
Prescription(char* Name,char* D,
CSE5810
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;
};
URBSOO-81
Prescription Implementation
CSE5810
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;
}
URBSOO-82
Comments on GEA

CSE5810 


Enhances BEA Advantages via Template
Software Reuse is Strongly promoted
Changes to Prescription/ Item Methods Don't Alter
Method Signatures
URBS Enforcement is Therefore Hidden
URBSOO-83
Advanced Exception Handling

CSE5810



Expand BEA and GEA with Advanced
Capabilities
Focus on Added Code to Process Security
Violations
Recast Generic Security Template Class with
Multiple Exceptions
Explore Hypothetical Examples
URBSOO-84
Revised Generic Security Template
template <class Type> class Gen_Security {
protected:
CSE5810 int C_ID; // Object ID
int M_ID; // Method ID
public:
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
URBSOO-85
Revised Generic Security Template
CSE5810
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
};
URBSOO-86
Revised Generic Security Template
template<class Type> void
Gen_Security<Type>::GS_Check_UR()
CSE5810 { // 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;
}
URBSOO-87
Compare/Contrast the Four Exception
Handling Based Approaches

CSE5810



How do the Four Approaches Compare?
 Extensibility
 Flexibility
 Hiding/Encapsulation
 Reusability
Is One Easier than Another?
How do they Rate vs. Earlier Three Approaches?
What’s Missing in the Process?
URBSOO-88