ifip 2000-1 profs. steven a. demurjian computer science & engineering department 191 auditorium...

IFIP 2000-1

Profs. Steven A. Demurjian Computer Science & Engineering Department

191 Auditorium Road, Box U-155The University of Connecticut

Storrs, Connecticut 06269-3155

http://www.engr.uconn.edu/[email protected]

Security for Distributed Computing Security for Distributed Computing

Security Issues for Distributed ComputingSecurity Issues for Distributed Computing A Proposed Distributed Security FrameworkA Proposed Distributed Security Framework Role-Based Security in a Distributed Resource Role-Based Security in a Distributed Resource

EnvironmentEnvironment

IFIP 2000-2

Security Issues for Distributed ComputingSecurity Issues for Distributed Computing

Background and MotivationBackground and Motivation What are Key Distributed Security Issues? What are Major/Underlying Security Concepts? What are Available Security Approaches?

Identifying Key Distributed Security RequirementsIdentifying Key Distributed Security Requirements Focusing on Discretionary Access Control (DAC) Focusing on Discretionary Access Control (DAC)

and User-Role Based Security (URBS) for OOand User-Role Based Security (URBS) for OO Propose Preliminary Security Techniques to Propose Preliminary Security Techniques to

Address OO and Non-OO Legacy/COTS Appls.Address OO and Non-OO Legacy/COTS Appls.

IFIP 2000-3

Security for Distributed Applications Security for Distributed Applications Comprised of DBs, Legacy, COTS, etc.Comprised of DBs, Legacy, COTS, etc.

Legacy

Legacy

Legacy

COTS

COTS

COTS

Database

Database

NETWORK

JavaClient

JavaClient

How is Security Handled How is Security Handled for Individual Systems?for Individual Systems?

What about Distributed What about Distributed Security?Security?

Security Issues for New Clients?Security Issues for New Clients?New Servers? Across Network?New Servers? Across Network?

What if Security Never Available What if Security Never Available for Legacy/COTS/Database?for Legacy/COTS/Database?

Security Policy, Model, Security Policy, Model, and Enforcement?and Enforcement?

IFIP 2000-4

Identifying Key Security RequirementsIdentifying Key Security Requirements What are Major Security Concepts? What are Major Security Concepts?

AuthenticationAuthentication

Is the Client who S/he Says they are?

AuthorizationAuthorization

Does the Client have Permission to do what S/he Wants?

PrivacyPrivacy

Is Anyone Intercepting Client/Server Communications?

Enforcement MechanismEnforcement Mechanism Centralized and Distributed “Code” Enforces Security Policy at Runtime

IFIP 2000-5

Identifying Key Security RequirementsIdentifying Key Security Requirements What are Underlying Security Concepts? What are Underlying Security Concepts?

AssuranceAssurance Are the Security Privileges for Each Client

Adequate to Support their Activities? Do the Security Privileges for Each Client

Meet but Not Exceed their Capabilities? ConsistencyConsistency

Are the Defined Security Privileges for Each Client Internally Consistent? Least-Privilege Principle: Just Enough Access

Are the Defined Security Privileges for Related Clients Globally Consistent? Mutual-Exclusion: Read for Some-Write for Others

IFIP 2000-6

Identifying Key Security RequirementsIdentifying Key Security Requirements 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

IFIP 2000-7

Identifying Key Security RequirementsIdentifying Key Security Requirements Three Categories of Questions Three Categories of Questions

Questions on Information Access and FlowQuestions on Information Access and Flow User Privileges key to Security Policy Information for Users and Between Users

Questions on Security Handlers and ProcessorsQuestions on Security Handlers and Processors Manage/Enforce Runtime Security Policy Coordination Across EC Nodes

Questions on Needs of Legacy/COTS Appls.Questions on Needs of Legacy/COTS Appls. Integrated, Interoperative Distributed

Application will have New Apps., Legacy/COTS, Future COTS

IFIP 2000-8

Questions on Questions on Information Access and FlowInformation Access and Flow

Who Can See What Information at What Time? Who Can See What Information at What Time? What Are the Security Requirements for Each

User Against Individual Legacy/cots Systems and for the Distributed Application?

What Information Needs to Be Sent to Which What Information Needs to Be Sent to Which Users at What Time? Users at What Time? What Information Should Be “Pushed” in an

Automated Fashion to Different Users at Regular Intervals?

IFIP 2000-9

Questions on Questions on Information Access and FlowInformation Access and Flow

What Information Needs to Be Available to Which What Information Needs to Be Available to Which Users at What Time? Users at What Time? What Information Needs to Be “Pulled” On-

demand to Satisfy Different User Needs in Time-critical Situations

How Are Changing User Requirements Addressed How Are Changing User Requirements Addressed Within the Distributed Computing Application? Within the Distributed Computing Application? Are User Privileges Static for the Distributed

Computing Application? Can User Privileges Change Based on the

“Context” and “State” of Application?

IFIP 2000-10

Questions on Security Questions on Security Handlers/ProcessingHandlers/Processing

What Security Techniques Are What Security Techniques Are Needed to Insure That the Correct Information

Is Sent to the Appropriate Users at Right Time? Necessary to Insure That Exactly Enough

Information and No More Is Available to Appropriate Users at Optimal Times?

Required to Allow As Much Information As Possible to Be Available on Demand to Authorized Users?

IFIP 2000-11


How Does the Design by Composition of a How Does the Design by Composition of a Distributed Computing Application Impact on Distributed Computing Application Impact on Both the Security and Delivery of Information? Both the Security and Delivery of Information? Is the Composition of Its “Secure”

Components Also Secure, Thereby Allowing the Delivery of Information?

Can We Design Reusable Security Components Can We Design Reusable Security Components That Can Be Composed on Demand to Support That Can Be Composed on Demand to Support Dynamic Security Needs in a Distributed Setting?Dynamic Security Needs in a Distributed Setting?

What Is the Impact of Legacy/cots Applications on Delivering the Information?

IFIP 2000-12


How Does Distribution Affect Security Policy Definition and Enforcement?

Are Security Handlers/enforcement Mechanisms Centralized And/or Distributed to Support Multiple, Diverse Security Policies?

Are There Customized Security Handlers/enforcement Mechanisms at Different Levels of Organizational Hierarchy? Does the Organizational Hierarchy Dictate the

Interactions of the Security Handlers for a Unified Enforcement Mechanism for Entire Distributed System?

IFIP 2000-13

Questions on Legacy/COTS ApplicationsQuestions on Legacy/COTS Applications

When Legacy/cots Appls. Are Placed Into When Legacy/cots Appls. Are Placed Into Distributed, Interoperable Environment: Distributed, Interoperable Environment: At What Level, If Any, Is Secure Access

Available? Does the Application Require That Secure

Access Be Addressed? How Is Security Added If It Is Not Present?

What Techniques Are Needed to Control Access to Legacy/COTS?

What Is the Impact of New Programming Languages (Procedural, Object-oriented, Etc.) And Paradigms?

IFIP 2000-14

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 Employed Inheritance, Generics, and Exceptions in C++/Ada95 Languages

Leverage Results as Starting Point

IFIP 2000-15

Legacy/COTS ApplicationsLegacy/COTS Applications

Interoperability of Legacy/COTS in a Distributed Interoperability of Legacy/COTS in a Distributed EnvironmentEnvironment

Security Issues in Interoperative, Distributed Security Issues in Interoperative, Distributed EnvironmentEnvironment Can DAC/URBS be Exploited? How are OO Legacy/COTS Handled? How are Non-OO Legacy/COTS Handled? How are New Java/C++ Appls. Incorporated? Can Java Security Capabilities be Utilized? What Does CORBA/ORBs have to Offer? What about other Middleware (e.g. JINI)?

Explore Some Preliminary Ideas on Select IssuesExplore Some Preliminary Ideas on Select Issues

IFIP 2000-16

Security for OO Legacy/COTSSecurity for OO Legacy/COTS

For OO Legacy/COTS, High Likelihood of Class For OO Legacy/COTS, High Likelihood of Class Based Programming InterfaceBased Programming Interface

Utilize Reviewed DAC/URBS Approaches:Utilize Reviewed DAC/URBS Approaches:

User-Role Subclassing Approach

OO Classesthat form theProgrammingInterface toLegacy/COTs,

e.g.,PatientRecord

Nu

rse_

Pat

ient

Rec

ord

and

MD

_Pat

ient

Rec

ord

Cla

sses

Cu

stom

er/U

ser

App

lica

tion

sA

gain

st N

urse

/MD

Cla

sses

Pat

ient

Rec

ord_

Exc

epti

on

Cla

ss E

xten

ds P

atie

ntR

ecw

ith

try/

catc

h/th

row

Basic Exception Approach

OO Classesthat form theProgrammingInterface toLegacy/COTs,

e.g.,PatientRecord

Cu

stom

er/U

ser

App

lica

tion

sA

gain

st P

atie

ntR

ecor

d_E

xcp

IFIP 2000-17

Security for Non-OO Legacy/COTSSecurity for Non-OO Legacy/COTS

For Non-OO Legacy/COTS, Programming For Non-OO Legacy/COTS, Programming Interface Likely a Set of System FunctionsInterface Likely a Set of System Functions

Utilize Reviewed DAC/URBS Approaches:Utilize Reviewed DAC/URBS Approaches:

User-Role Subclassing Approach

Set of System Functionsthat form the Pgmmg.Interface toLegacy orCOTS

Cu

stom

er/U

ser

App

lica

tion

sA

gain

st E

xcep

tion

Cla

sses

Basic Exception Approach

Set of System Functionsthat form the Pgmmg.Interface toLegacy orCOTS

OO

Wra

pper

of

Cla

sses

wit

h M

eth

ods

that

Inv

oke

Fu

ncti

ons

Use

r-R

ole

Sub

clas

ses

, e.g

.,M

D_P

atie

ntR

ecor

d fo

r

Cu

stom

er/U

ser

App

lica

tion

sA

gain

st U

ser-

Rol

e Su

bcla

sses

OO

Wra

pper

of

Cla

sses

wit

h M

eth

ods

that

Inv

oke

Fu

ncti

ons

Exc

epti

on C

lass

es E

xten

d O

OW

rap

per

Cla

sses

-try

/cat

ch/t

hw

IFIP 2000-18

A Distributed Security Framework A Distributed Security Framework Motivation and IssuesMotivation and Issues

What is Needed for the Definition and Realization What is Needed for the Definition and Realization of Security for a Distributed Application?of Security for a Distributed Application?

How can we Dynamically Construct and Maintain How can we Dynamically Construct and Maintain Security for a Distributed Application?Security for a Distributed Application? Application Requirements Change Over Time Seamless Transition for Changes Transparency from both User and Distributed

Application Perspectives What are Parts of Distributed Security Framework? What are Parts of Distributed Security Framework?

IFIP 2000-19

A Distributed Security FrameworkA Distributed Security Framework

Distributed Security Policy Definition, Planning, Distributed Security Policy Definition, Planning, and Managementand Management Exactly Define Security Policy Manage Policy in Changing Environment

Formal Security Model w. Reusable ComponentsFormal Security Model w. Reusable Components Formal Realization of Security Policy Reusable “Security” Components

Security Handlers & Enforcement MechanismSecurity Handlers & Enforcement Mechanism Run-time Techniques and Processes Allows Dynamic Changes to Policy to be

Seamless and Transparently Made

IFIP 2000-20

L + SH DB + SH

JavaClient

JavaClient

LegacyClient DB Client

COTSClient

L + SH CO+ SHDB + SH Server + SH

L + SHCO+ SH Server + SHDB + SH

Formal Security Model

Distributed Security Policy

Reusable Security Components

Enforcement Mechanism Collection of SHs

L: Legacy CO: COTS DB: Database SH: Security Handler

A Distributed Security FrameworkA Distributed Security FrameworkInteractions and DependenciesInteractions and Dependencies

IFIP 2000-21

Distributed Security Policy Definition, Distributed Security Policy Definition, Planning, and ManagementPlanning, and Management

Interplay of Security Requirements, Security Interplay of Security Requirements, Security Officers, Users, Components and Overall SystemOfficers, Users, Components and Overall System

Minimal Effort in Distributed Setting - CORBA Minimal Effort in Distributed Setting - CORBA Has Services forHas Services for Confidentiality, Integrity, Accountability, and

Availability But, No Cohesive CORBA Service Ties Them

with Authorization, Authentication, and Privacy Difficult to Accomplish in Distributed Setting

Must Understand All Constituent Systems Interplay of Stakeholders, Users, Sec. Officers

IFIP 2000-22

Formal Security Model withFormal Security Model with Reusable Components Reusable Components

Constructive Means to Capture Distributed Constructive Means to Capture Distributed Security PolicySecurity Policy

Transitional Intermediate Form to Actual Transitional Intermediate Form to Actual “Reusable” Security Components “Reusable” Security Components

Possible ApproachPossible Approach Upgrade URDH/Role-Based OO Work to

Distributed Service-Based Approach Utilize DRE for Analyzing Reusability of

Security Components Change/Extend DRE for Analyzing Security

Dependencies - e.g., Chaining of Calls

IFIP 2000-23

Security Handlers andSecurity Handlers and Enforcement Mechanism Enforcement Mechanism

Provide Concrete Means That Distributed Security Provide Concrete Means That Distributed Security Policy As Captured by the Formal Security Model Policy As Captured by the Formal Security Model Is Dynamically Attained in Runtime SettingIs Dynamically Attained in Runtime Setting

Can our Prior Approaches be Leveraged?Can our Prior Approaches be Leveraged? URSA, UCLA, BEA, GEA, etc. Agent-Based URBS Security Capabilities of Java

What are Potential Middleware Solutions?What are Potential Middleware Solutions? CORBA JINI XML (XMI)

IFIP 2000-24

Contributions of the FrameworkContributions of the Framework

Integration of URBS Techniques and Reusability Integration of URBS Techniques and Reusability Analysis May Lead to … Analysis May Lead to … Security Components That Are Reusable

Within an Organization’s Domain Security Components Proven Correct When Security Components Proven Correct When

Reused, Carry Correctness to Other SettingsReused, Carry Correctness to Other Settings Assurance to Security Officers That the

Defined Policy Continues to Be Enforced Modifications to Dependency Analysis (DRE) to Modifications to Dependency Analysis (DRE) to

Include Security Requirements and Roles Offers Include Security Requirements and Roles Offers Another Dimension on Reusable D & DAnother Dimension on Reusable D & D

IFIP 2000-25

Profs. Steven A. Demurjian and T.C. TingJ. Balthazar, H. Ren, and C. PhillipsComputer Science & Engineering Dept.

191 Auditorium Road, Box U-155The University of Connecticut

Storrs, Connecticut 06269-3155

http://www.engr.uconn.edu/[email protected]

Role-Based Security in a Distributed Role-Based Security in a Distributed Resource Environment*Resource Environment*

Dr. Paul BarrThe MITRE Corp145 Wyckoff Road

Eatontown, New Jersey [email protected]

*This work presented at IFIP WG 11.3 on DB Security in August 2000,and supported in part by a research contract from the

Mitre Corporation (Eatontown, NJ) and a research grant from AFOSR

IFIP 2000-26

OverviewOverview

Motivation and Goals of Our Research EffortMotivation and Goals of Our Research Effort Sun’s JINI TechnologySun’s JINI Technology A Software Architecture for Role-Based SecurityA Software Architecture for Role-Based Security

Proposed Software Architecture Security Resources and Services Security Client and Resource Interactions Client Interactions and Processing

Experimental Prototypes Experimental Prototypes JINI Prototype of Role Based Approach Security Client Prototype

Related WorkRelated Work Conclusions and Future WorkConclusions and Future Work

IFIP 2000-27

Overview of the Security Process for a Overview of the Security Process for a Distributed ApplicationDistributed Application

Focus on Role-Based Security Focus on Role-Based Security Within ApplicationWithin Application Clients Play Role Role Dictates Look and Feel

of Client Software Role Passed Along to

“Systems” that Comprise Distributed Application

Distributed Application MustDistributed Application Must Contain “Security Software” How is Security Captured? How is Security Enforced? How Do Clients Interact with

Distributed Application?

IFIP 2000-28

Goals of Our Research EffortGoals of Our Research Effort

Incorporation of Role-Based Approach within Incorporation of Role-Based Approach within Distributed Resource EnvironmentDistributed Resource Environment Highly-Available Distributed Applications

Constructed Using Middleware Tools Demonstrate Use of JINI to Provide Selective

Access of Clients to Resources Based on Role Propose Software Architecture and Role-Based Propose Software Architecture and Role-Based

Security Model forSecurity Model for Authorization of Clients Based on Role Authentication of Clients and Resources Enforcement so Clients Only Use Authorized

Services (of Resource) Propose Security Solution for Distributed Propose Security Solution for Distributed

Applications for Clients and Services (Resources)Applications for Clients and Services (Resources)

IFIP 2000-29

Sun’s JINI TechnologySun’s JINI Technology

Construct Distributed Applications Using JINI by Construct Distributed Applications Using JINI by Federating Groups of Users Resources Provide Services for Users

A A ResourceResource Provides a Set of Services for Use by Provides a Set of Services for Use by Clients (Users) and Other Resources (Services)Clients (Users) and Other Resources (Services)

A A ServiceService is Similar to a Public Method is Similar to a Public Method Exportable - Analogous to API Any Entity Utilized by Person or Program Samples Include:

Computation, Persistent Store, Printer, Sensor Software Filter, Real-Time Data Source

Services: Concrete Interfaces of Components Services Register with Services Register with Lookup ServiceLookup Service

IFIP 2000-30

Sun’s JINI TechnologySun’s JINI TechnologyKey JINI Concepts and TermsKey JINI Concepts and Terms

RegistrationRegistration of Services via of Services via Leasing MechanismLeasing Mechanism Resource Leases Services to Lookup Service Resources Renew Services Prior to Expiration If not, Services Become Unavailable Lookup Service Maintains Registry Services as Available “Components”

Leasing Supports High-AvailabilityLeasing Supports High-Availability Registration and Renewal Process Upon Failure, Services Removed from Registry

Clients, Resources, Lookup Can Occupy Same or Clients, Resources, Lookup Can Occupy Same or Different Computing NodesDifferent Computing Nodes

IFIP 2000-31

Sun’s JINI TechnologySun’s JINI TechnologyJoin, Lookup, and Service InvocationJoin, Lookup, and Service Invocation

ClientResource

Service ObjectService Attributes

Lookup ServiceRequestServiceAddCourse(CSE900)

ReturnService

Proxy toAddCourse( )

Join

Register & Lease Services CourseDB ClassContains Method AddCourse ( )

1. Client Invokes AddCourse(CSE900) on Resource2. Resource Returns Status of Invocation

Service Invocation via Proxy by Transparent RMI Call

Service Object

Service Attributes

Registry of Entries

IFIP 2000-32

Security within JINI Security within JINI Limitations and PotentialLimitations and Potential

Provides Minimal Support for Application Level Provides Minimal Support for Application Level SecuritySecurity

Registration Process by Resources of Services Registration Process by Resources of Services Doesn’t Allow “Who Can Use Which Service”Doesn’t Allow “Who Can Use Which Service”

Consequently, Resources Using JINI Would Consequently, Resources Using JINI Would Require Programmatic Solution for SecurityRequire Programmatic Solution for Security Requires Code-Level Changes Recompilation and Rebuild Can’t Adjust Dynamically When Privileges

Must be Changed Can a Distributed Resource Environment (JINI) Can a Distributed Resource Environment (JINI)

be Exploited to Allow Role-Based Security be Exploited to Allow Role-Based Security Consistent with its Philosophy and Use?Consistent with its Philosophy and Use?

IFIP 2000-33

Role-Based Security within JINI Role-Based Security within JINI A Proposed Solution ApproachA Proposed Solution Approach

Define Resources to Manage and Control SecurityDefine Resources to Manage and Control Security Role-Based Privileges:

What are the Defined User Roles (e.g. URDH)? Which Role can Use Which Service(s) of Each

Resource? Allow Access Down to Method Level

Authorization List: Who are the Users? What are Their Authorized Role(s)?

Security Registration: Who are Active Users? How is User Uniquely Identified?

IFIP 2000-34

Proposed Software ArchitectureProposed Software Architecturefor Role-Based Securityfor Role-Based Security

Resources Provide ServicesClients Using Services

Figure 3.1: General Architecture of Clients and Resources.

Role-BasedPrivileges

AuthorizationList

Security Registration

Legacy

COTS

COTS

Database

Database

LookupService

LookupService

JavaClient

JavaClient

LegacyClient

DatabaseClient

SoftwareAgent

COTSClient

IFIP 2000-35

Security Resources and ServicesSecurity Resources and Services

Role-Based Privileges ResourceRole-Based Privileges Resource Define User-role Grant/Revoke Access of Role to Resource Register Services

Authorization List ResourceAuthorization List Resource Maintains Client Profile (Many Client Types) Client Profile and Authorize Role Services

Security Registration ResourceSecurity Registration Resource Register Client Service Identity Registration at Startup Uses IP Address

Security ClientSecurity Client Allow Security Officer to Set, Change, Monitor,

and Manage the Three Security Resources

IFIP 2000-36

Defining a Base Line Security Model for Defining a Base Line Security Model for Distributed ComputingDistributed Computing

Definition 1:Definition 1: A A ResourceResource Is a System (E.G., A Is a System (E.G., A Legacy, COTS, Database, Web Server, Etc.) That Legacy, COTS, Database, Web Server, Etc.) That Provides Functions for the Distributed Application Provides Functions for the Distributed Application Via a Collection of Via a Collection of N N Services. Services.

Definition 2: Definition 2: A A ServiceService Is Composed of Multiple Is Composed of Multiple MethodsMethods Each Method Is Akin to OO Method Each Method Represents a Subset of the

Functionality Provided by the Service Definition 3Definition 3: A Method of a Service Is

Characterized by a Signature

IFIP 2000-37


Definitions 4: Each Resource Has a Unique Resource

Identifier to Differentiate Between Replicated Resources

Definitions 5: Each Service Has a Unique Service Identifier

to Distinguish Services Within a Particular Resource

Definitions 6: Each Method Has a Unique Method Signature

to Distinguish Methods of a Service

IFIP 2000-38


Definition 7:Definition 7: A A User RoleUser Role, , URUR, Is a Uniquely , Is a Uniquely Named Entity for a Specific Set of Responsibilities Named Entity for a Specific Set of Responsibilities Against an Application With Privileges Are Against an Application With Privileges Are Granted and Revoked As Follows:Granted and Revoked As Follows: UR Can Be Granted Access to Resource R,

Implying It Can Utilize All of R's Services, and Their Methods

UR Can Be Granted Access to a Subset of the Services of Resource R, Denoting That UR Can Utilize All of the Methods Defined by That Subset

UR Can Be Granted Specific Access to Individual Methods Via Triple <Resource Id, Service Id, Method Signature>

IFIP 2000-39

Role-Based Privileges ResourceRole-Based Privileges Resource

Define User-role, Grant/revoke Access of Role to Define User-role, Grant/revoke Access of Role to Resource, and Registration of Resource’s ServicesResource, and Registration of Resource’s Services

Maintains Following Information:Maintains Following Information: Resource List Indexed by <Resource Identifier> and

All of URs Granted Access to Resource Service List Indexed by <Resource Identifier, Service

Identifier> and All URs Granted Access to Service Method List Indexed by <Resource Identifier, Service

Identifier, Method Signature> and All URs Granted Access to Each Method

User-role List Indexed by <Role Name, Role Identifier>, and for Each UR All Resources, Services, Methods, Granted Access

IFIP 2000-40

The Services of theThe Services of theRole-Based Privilege ResourceRole-Based Privilege Resource

Figure 3.2: The Services and Methods for Security Resources.

Register Client Service Register_Client(C_Id, IP_Addr, UR); UnRegister_Client(C_Id, IP_Addr, UR); IsClient_Registered(C_Id); Find_Client(C_Id, IP_Addr); Find_All_Active_Clients();

Authorization-List Services

Security Registration Services

Authorize Role Service Grant_UR_Client(UR_Id, C_Id); Revoke_UR_Client(UR, C_Id); Find_AllUR_Client(C_Id); Verify_UR_Client(UR, C_Id); Find_All_Clients_UR(UR);

Client Profile Service Create_New_Client(C_Id); Delete_Client(C_Id); Find_Client(C_Id); Find_All_Clients();

Register Service Register_Resource(R_Id); Register_Service(R_Id, S_Id); Register_Method(R_Id, S_Id, M_Id); UnRegister_Resource(R_Id); UnRegister_Service(R_Id, S_Id); UnRegister_Method(R_Id, S_Id, M_Id);

Query Privileges Service Check_Privileges(UR_Id, R_Id, S_Id, M_Id);

Grant-Revoke Service Grant_Resource(UR_Id, R_Id); Grant_Service(UR_Id, R_Id, S_Id); Grant_Method(UR_Id, R_Id, S_Id, M_Id); Revoke_Resource(UR, R_Id); Revoke_Service(UR, R_Id, S_Id); Revoke_Method(UR, R_Id, S_Id, M_Id); Find_AllUR_Resource(R_Id); Find_AllUR_Service(R_Id, S_Id); Find_AllUR_Method(R_Id, S_Id, M_Id); Find_UR_Privileges(UR);

User Role Service Create_New_Role(UR_Name, UR_Disc, UR_Id); Delete_Role(UR_Id); Find_UR_Name(UR_Name); Find_UR_Id(UR_Id);

Role-Based Privileges Services

IFIP 2000-41

Authorization List ResourceAuthorization List Resource

Maintains Client Profile (Many Client Types) and Maintains Client Profile (Many Client Types) and Ability to Authorize Role ServicesAbility to Authorize Role Services

Definition 8: A Client Profile, CP, Characterizes All of the

Pertinent Information on Client (User, Tool, Software Agent, Etc.)

A CP Used by Resource to Dynamically Verify Whether a Client Can Access the Desired Triple of <Resource Identifier, Service Identifier, Method Signature>

Addresses Issues Such As: Addresses Issues Such As: Has Client Registered? Is Client ID Accurate? Etc.Has Client Registered? Is Client ID Accurate? Etc.

IFIP 2000-42

The Services of theThe Services of theAuthorization-List ResourceAuthorization-List Resource












IFIP 2000-43

Security Registration ResourceSecurity Registration Resource

Utilized to Register Client Service, Identity Utilized to Register Client Service, Identity Registration at Startup, and Uses IP AddressRegistration at Startup, and Uses IP Address

Usage by ClientUsage by Client When Client First Begins Session Establish Client Id, IP Address, and User Role

Usage by Resource to Determine If a Client Has Usage by Resource to Determine If a Client Has RegisteredRegistered

Usage by Security Client to Maintain and Query Usage by Security Client to Maintain and Query PrivilegesPrivileges

IFIP 2000-44

The Services of theThe Services of theSecurity Registration ResourceSecurity Registration Resource












IFIP 2000-45

Security Client and Resource InteractionsSecurity Client and Resource Interactions

Figure 3.3: Security Client and Database Resource Interactions.


AuthorizationList


LookupService

SecurityClient

Find_Client(C_Id, IP_Addr); Find_All_Active_Clients();

Discover Service Return Proxy

GeneralResource

Grant_UR_Client(UR_Id, C_Id); Revoke_UR_Client(UR, C_Id); Find_AllUR_Client(C_Id); Find_All_Clients_UR(UR);

Create_New_Role(UR_Name, UR_Disc, UR_Id); Delete_Role(UR_Id); Find_UR_Name(UR_Name); Find_UR_Id(UR_Id); Grant_Resource(UR_Id, R_Id); Grant_Service(UR_Id, R_Id, S_Id); Grant_Method(UR_Id, R_Id, S_Id, M_Id); Revoke_Resource(UR, R_Id); Revoke_Service(UR, R_Id, S_Id); Revoke_Method(UR, R_Id, S_Id, M_Id); Find_AllUR_Resource(UR,R_Id); Find_AllUR_Service(UR,R_Id,S_Id); Find_AllUR_Method(UR,R_Id,S_Id,M_Id); Find_UR_Privileges(UR);

Register_Resource(R_Id); Register_Service(R_Id, S_Id);Register_Method(R_Id, S_Id, M_Id);UnRegister_Resource(R_Id);UnRegister_Service(R_Id, S_Id);UnRegister_Method(R_Id, S_Id, M_Id);

Create_New_Client(C_Id); Delete_Client(C_Id); Find_Client(C_Id); Find_All_Clients();

IFIP 2000-46

8. Check_Privileges(UR,R_Id,S_Id,M_Id);

Client Interactions and ProcessingClient Interactions and Processing

DatabaseResource

Figure 3.4: Client Interactions and Service Invocations.


AuthorizationList


LookupService

GUIClient

1. Register_Client(C_Id, IP_Addr,UR);

2. Verify_UR_Client(UR,C_Id);

Discover Service Return Proxy

3. Client OK?

4. Registration OK?

5. ModifyAttr(C_ID,UR,Value)

6.IsClient_Registered(C_ID)

7. Registration OK?

9. Privileges OK?

10. Modification OK?

IFIP 2000-47

Two Experimental PrototypesTwo Experimental Prototypes

JINI Prototype of Role Based ApproachJINI Prototype of Role Based Approach University Database (UDB) Initial GUI for Sign In (Authorization List) Student/faculty GUI Client (Coursedb) Access to Methods Limited Based on Role

(Ex: Only Student Can Enroll in a Course) Security Client Prototype Security Client Prototype

Generic Tool Uses Three Resources and Their Services

Role-Based Privileges Authorization-List Security Registration

IFIP 2000-48

Experimental Prototype OneExperimental Prototype One JINI Prototype of Role Based Approach JINI Prototype of Role Based Approach

Figure 4.1: An Architecture of URBS based on JINI Technology.

JavaGUI

Client1

JINILookupService

Author.List Res.(copy 2)

Author.List Res.(copy 1)

Role-BasedPrivileges &

Sec. Reg.

JavaGUI

Client2

CourseDBResource(copy 1)

CourseDBResource(copy 2)

Role-BasedPrivileges &

Sec. Reg.

DBServer Service GetClasses(); PreReqCourse(); GetVacantClasses(); EnrollCourse(); AddCourse(); RemoveCourse(); UpdateCourse().

IFIP 2000-49

Experimental Prototype OneExperimental Prototype OneExecution ProcessExecution Process

Figure 4.2: Execution Process for Architecture.

JavaGUI

Client1

JINILookupService

Role-BasePrivileges &

Sec. Reg.

1a, 5a

1b, 5b

2

4

6

CourseDBResource

8a

9a 8b

9b10

7a 7b

Author.List Res.

3aa3b

1a. Discover Register_Client Service1b. Return Service Proxy2. Register the Client3a. Is Client Authorized?3b. Succeed - return Role4. Return Success or Failure5a. Discover CourseDB Service5b. Return Service Proxy6. Invoke a Method, e.g., Invoke EnrollCourse()7a. Discover Role-Based Priv. & Sec. Reg. Services7b. Return Service Proxies8a. Is Client Registered?8b. Return Yes or No9a. Can Client Invoke Method?10. addCourse() or do nothing

IFIP 2000-50

Experimental Prototype TwoExperimental Prototype TwoThe Security Client PrototypeThe Security Client Prototype

Figure 4.3: Initial Security Client Screen.

IFIP 2000-51

RecallRecallSecurity Resources and ServicesSecurity Resources and Services












IFIP 2000-52

Experimental Prototype TwoExperimental Prototype TwoRole-Based Privilege Resource & ServicesRole-Based Privilege Resource & Services

Figure 4.4: The Role-Based Privileges Services Screen

IFIP 2000-53

Experimental Prototype TwoExperimental Prototype Two Authorization List Resource & Services Authorization List Resource & Services

Figure 4.5: The Authorization-List Services Screen.

IFIP 2000-54

Experimental Prototype TwoExperimental Prototype Two Security Registration Resource & Services Security Registration Resource & Services

Figure 4.6: The Security Registration Services Screen.

IFIP 2000-55

Related WorkRelated Work

Security Policy & Security Policy & Enforcement (OS Security)Enforcement (OS Security) Security Filters and

Screens Header Encryption User-level Authen. IP Encapsulation Key Mgmt. Protocols Browser Security

Use of EncryptionUse of Encryption Access Control Securing Comm.

Channel Establishing a Trusted

Computer Base Network Services

Kerberos & Charon

Security: Mobile AgentsSecurity: Mobile Agents Saga Security

Architecture Access Tokens Control Vectors Security Monitor

Concordia Storage Protection Transmission Protection Server Resource

Protection Other Topics

Trust Appraisal Metric Analysis Short-lived Certificates Seamless Object

Authentication

IFIP 2000-56

ConclusionsConclusions

For a Distributed Resource EnvironmentFor a Distributed Resource Environment Proposed & Explained a Role-Based Approach Authorize, Authenticate, and Enforce

Presented an Software Architecture ContainingPresented an Software Architecture Containing Role-Based Security Model for a Distributed

Resource Environment Security Registration, Authorization-List, and

Role-based Privileges Resources Developed Two Independent PrototypesDeveloped Two Independent Prototypes

JINI-Based Prototype for Role-Based Security Model that Allows Clients to Access Resources Based on Role

Security Client for Establishing Privileges

IFIP 2000-57

Future WorkFuture Work

Negative PrivilegesNegative Privileges Chaining of Resource Invocations Client Uses S1 on R1 that Calls S2 on R2 Client Authorized to S1 but Not S2

Multiple Security ClientsMultiple Security Clients What Happens When Multiple Security Clients

Attempt to Modify Privileges at Same Time? Is Data Consistency Assured?

Leasing Concept available with JINILeasing Concept available with JINI Leasing Allows Services to Expire Can Role-Based Privileges Also Expire?

IFIP 2000-58

Future WorkFuture Work

Location of Client vs. Affect on ServiceLocation of Client vs. Affect on Service What if Client in on Local Intranet? What if Client is on WAN? Are Privileges Different?

Tracking Computation for Identification PurposesTracking Computation for Identification Purposes Currently Require Name, Role, IP Addr, Port # How is this Tracked when Dynamic IP

Addresses are Utilized? Integration of the the Two PrototypesIntegration of the the Two Prototypes

Combining Both Prototypes into Working System

Likely Semester Project during Fall 2000

ifip 2000-1 profs. steven a. demurjian computer science & engineering department 191 auditorium...

Documents

id register

id revoke

id grant

sessionestablish client

client id accurate

register service register

client service

security client