a question… cs489/589: access control & system securitydoshin/t/s10/cs589/docs/note3.pdf ·...

1

CS489/589: CS489/589: Access Control & Access Control & System SecuritySystem Security

A Designated Center of Academic Excellence in Information Assurance Education by the National Security Agency

System SecuritySystem Security

Lecture 3

: Role‐based Access Control (RBAC) Model

A Question…

Computer security beyond OSesThe advent of the Internet, e‐business

Network security solution (SSL)

2

Public key infrastructure

Access control

So, what was the biggest challenge in enterprise‐wise access control management?

Another Question

Then, what is the difference between roles and other intermediaries such as security labels?

3

Role‐based Access Control ( )


(RBAC)

RBAC

A mechanism which allows and promotes an organization‐specific AC policy based on roles

Enabling to support the development and adoption of new complex networked security systems with significant

5

new complex networked security systems with significant contribution

The net benefits through 2006 are $671.1 million. [NIST Planning Report 02‐01, 2002]

Has become widely accepted as the proven technologyMany organizations based access control decisions on the roles that individual users take on as part of organizations

Why RBAC

Reasons to use rolesExpressive power

Stability

RBAC security principles

6

RBAC security principlesLeast privilege

Separation of duties

Abstract operations

2

RBAC Models

RBAC96 FamilyRBAC0: Basic Model

RBAC1: Hierarchical Roles

RBAC2: Constrained Roles

7

RBAC3: RBAC1 + RBAC2

RBAC96 Family

8

RBAC0

U PPERMIS

RUSER

ASSIGNMENT

UA

9

USERS SIONROLES

PERMISSION ASSIGNMENT

PA

.

.

user roles

SESSIONS

S

RBAC0: Formal Expressions

U, R, P, S (users, roles, permissions, and sessions)

UA ⊆ U × R (user assignment)

PA ⊆ P × R (permission assignment)

10

user: S → U

roles: S → 2R

Requires roles(s) ⊆ { r | (user(s), r) ∈ UA }

Why Roles

Fewer relationships to manageFrom O(mn) to O(m+n), where m is the number of users and n is the number of permissions

Roles add a useful level of indirection

11

RBAC1

Director

12

ProductionEngineer 1

Project Lead 1

Quality Engineer 1


Project Lead 2

Quality Engineer 2

3

RBAC1: Formal Expressions

U, R, P, S, UA, PA, and user unchanged from RBAC0

RH ⊆ R × R : a partial order on R, written as ≥

roles: S → 2R

R i l ( ) { | ∃ ’ ≥ [ ( ( ) ’) UA] }

13

Requires roles(s) ⊆ { r | ∃ r’ ≥ r [ (user(s), r’) ∈ UA] }

Role Hierarchies

User inheritancer1 ≥ r2 means every user that is a member of r1 is also a member of r2

Permission inheritance

14

r1 ≥ r2 means every permission that is authorized for r2 is also authorized for r1

Activation inheritancer1 ≥ r2 means that activating r1 will also activate r2


Project Lead 1

Quality Engineer 1

RBAC2

No formal model specified

Constraints are addedMutually exclusive roles

Cardinality

15

Cardinality

Constraints are for laying out higher level organization policy

RBAC3

16

RBAC3

R

U

P

ROLE HIERARCHY

USER ASSIGNMENT

RH UA

17

ROLES USERS PERMISS-ION

PERMISSION ASSIGNMENT

PA . . CONSTRAINTS

user roles

SESSIONS S

Users

Users areHuman beings or

Other active agents

Each individual should be known as exactly one user

18

Each individual should be known as exactly one user

4

Roles as Policy

A role brings togetherA collection of users and

A collection of permissions

These collections will vary over time

19

These collections will vary over timeA role has significance and meaning beyond the particular users and permissions brought together at any moment

A Question?

What is the difference between groups and roles?A group often defined as

A collection of users

A role

20

A collection of users and

A collection of permissions

Some authors define role asA collection of permissions

Hierarchical Roles

21

Permissions

Primitive permissionsread, write, append, execute, etc

Abstract permissionscredit debit inquiry

22

credit, debit, inquiry

Permissions

Permissions are positive

No negative permissions or denialsNegative permissions and denials can be handled by constraints

23

User‐Role Assignment

A user can be a member of many roles

Each role can have many users as members

URA97 model

24

5

Implicit User Assignment

25

Explicit User Assignment

26

Permission‐Role Assignment

A permission can be assigned to many roles

Each role can have many permissions

27

Sessions

A user can invoke multiple sessions

In each session a user can invoke any subset of roles that the user is a member of

28

Constraints

Applied to all components in RBAC

Example: mutually exclusive rolesStatic exclusion: the same individual can never hold both roles

Dynamic exclusion: the same individual can never hold both roles

29

Dynamic exclusion: the same individual can never hold both roles in the same context

Separation of Duty

30

6

Expressive Power

Can be configured to do MACRoles simulate clearances

Can be configured to do DACRoles simulate identity

31

Roles simulate identity

ARBAC97 Model for Role‐b d d i i i f l


based Administration of Roles

Goal

Decentralize the administration of RBAC, i.e., allowing others to change parts of

(UA, PA, RH)

Overview

33

Overview There exist a set of administrative roles that are disjoint from the regular roles

ARBAC97

34

Role Hierarchies

35

URA97 Grant Model

Prerequisite conditione.g., r1∨(r2∧¬r3) is such a condition

can_assigne g can assign(a cond {r4 r5 r6})

36

e.g., can_assign(a, cond, {r4,r5,r6})

can_revokee.g., can_revoke(a, {r4,r5})

7

URA97 Grant Model

can‐assign

37

URA97 Revoke Model

can‐revoke

38

URA97 Revoke Model

Strong revocationRevokes explicit membership in a role and its seniors

Authorized only if corresponding weak revokes are authorized

Weak revocation

39

Weak revocationRevokes explicit membership in a role

PRA97

Treat permission assignments as dual to user assignmentcan_assign

e.g., can_assign(a, cond, {r4,r5,r6})

can_revoke

40

_e.g., can_revoke(a, {r4,r5})

RolePartner: l d i i i l


A Role Administration Tool

Role Administration (RA)

DefinitionRA is administrative routine works for implemented RBAC.

GoalRA is to manage and maintain the designed and implemented roles. Administration of roles should be done cautiously so as not to diverge from organizational security policies.

FunctionalityRA enables roles and role hierarchies to be managed properly in conjunction with users. It involves user assignment, constraints present in user assignment, in addition to the other components in implemented RBAC.

42

8

RA Methodology

Reorganization of RBAC components into three management constituents in order to reflect structural and behavioral characteristics in role administration

Structural components

Functional components

Informational components

Represent both semantics and syntaxes of U, R, P, RH, Ob, Op, and C.

Represent UA and PA, in addition to USERS and ROLES.

Represent repositories such as the LDAP directory

43

RolePartner: Design

Model‐drivenRBAC96 reference modelsARBAC97

Component‐basedComponents in the models are mapped to RolePartner components

Design proceduresRequirement specificationComponent specification

Structural overviewOperational architecturedatabase design

44

Design Goals

EasyEasy ofof UseUse StandardizationStandardization

User-Friendly GUI- Role-centric view for easily managing associated users and permissions.

Complete Support for RBAC Functionalities- Able to build full RBAC structural and functional components.

EasyEasy--ofof--UseUse StandardizationStandardization

AvailabilityAvailability ApplicabilityApplicability

Available in different system environments- Platform-independence of, the support of various formats of authorization policies in, and scalability of the system

Applicable in different organizational policy environments- Flexible enough to be configured and customized

45

Functional Requirement

•Add/delete/display roles• Add/delete/display permissions• Assign permissions to roles• Set/drop constraints

F i R l

•Add/delete/display roles• Add/delete/display permissions• Assign permissions to roles• Set/drop constraints

F i R l• Function Roles• Function Roles

•Add/delete/display users • Assign users to roles • Set/drop constraints• Function Users

•Add/delete/display users • Assign users to roles • Set/drop constraints• Function Users

46

Structural Overview

User Interface (GUI)User Interface (GUI)

Executive Services (ES)Executive Services (ES)

Network Interface (NI)Network Interface (NI)

Data Encoding Service (DES)Data Encoding Service (DES)

RBAC Structural RBAC Structural Service (RSS)Service (RSS)

RBAC Constraint RBAC Constraint Service (RCS)Service (RCS)

RBAC Functional RBAC Functional Service (RFS)Service (RFS)

Data Synchronization Service (DSS)Data Synchronization Service (DSS)

47

Operational Architecture

User Interface

(UI)

Role Administrator

1. Interact for management of role-based infrastructure environment.

Build role, role-hierarchy, permission,

dEncode data into

DES

Directory Server

Network Interface

(NI)

RSS

RCS

Executive Service (ES)

RFS

RolePartner

and user.

Build constraints which will be applied to RFS, RSS

Build assignment relations among roles, users, and permissions

appropriate format

Establish network connection to LDAP server

Role Database Connection

DSS

48

9

Sequence DiagramU I : U I W o r k e r E S : E S F a c a d e E S : F u n c C o m p W o r k e r N I : n iW o r k e rE S : C o n s t C o m p W o r k e r E S : S y n c W o r k e r E S : D i r E v e n t N o t i f ie r

a s s i g n U 2 R ( )

a s s i g n U s e r 2 R o le ( )

c h e c k C a r d iC o n s t r a in t ( )

c h e c k S O D C o n s t r a i n t ( )

c h e c k P r e r e q C o n s t r a in t ( )

t h e U s e r S C o m p

t h e R o le S C o m p

M o d i f ie d U s e r S C o m p

a s s ig n U s e r 2 R o le ( )

m o d i f yN a m in g E v e n t ( m o d i f y )

n o t i f y ( )

c h e c k V a lu e ( )

n o t i f y ( )

u p d a t e P o o l ( )

a s k U s e r ( )

c o n f i r m ( )

c o n f i r m ( )

m o d i f y

n o t i f y ( )

n o t i f y ( )

a s k U s e r ( )

c o n f i r m ( )

c o n f i r m ( )

c h e c k V a lu e ( )

M o d i f ie d R o l e S C o m p

u p d a t e P o o l ( )

t h e M o d i f ie d U s e r S C o m p

t h e M o d i f ie d R o le S C o m p

N a m in g E v e n t ( m o d i f y )

49

Directory service (Role DB)RBAC

rpcUser rpcPermissionrpcRole rpcConstraint Logs

rpcCardiConstraint rpcSODConstraint rpcPrereqConstraintrpcObject rpcOperation

No Name OID Notes

11 rpcUserrpcUser RPRP--OID.2.1OID.2.1 User information in RBAC serviceUser information in RBAC service

22 rpcRolerpcRole RPRP--OID.2.2OID.2.2 Role information in RBAC serviceRole information in RBAC service

33 rpcPermissionrpcPermission RPRP--OID.2.3OID.2.3 Permission information in RBAC servicePermission information in RBAC service

44 rpcObjectrpcObject RPRP--OID.2.4OID.2.4 Object information in RBAC serviceObject information in RBAC service

55 rpcOperationrpcOperation RPRP--OID.2.5OID.2.5 Operation information in RBAC serviceOperation information in RBAC service

66 rpcConstraintrpcConstraint RPRP--OID.2.6OID.2.6 Constraint information in RBAC serviceConstraint information in RBAC service

77 rpcCardiConstraintrpcCardiConstraint RPRP--OID.2.7OID.2.7 Cardinality constraint information in RBAC serviceCardinality constraint information in RBAC service

88 rpcSODConstraintrpcSODConstraint RPRP--OID.2.8OID.2.8 SOD constraint information in RBAC serviceSOD constraint information in RBAC service

99 rpcPrereqConstraintrpcPrereqConstraint RPRP--OID.2.9OID.2.9 Prerequisite constraint information in RBAC servicePrerequisite constraint information in RBAC service

50

RolePartner

51

Constraint Designer

52

Deployment Models

Get roles as a managed

CIM-based Authorization Domain

Generic Role-Based Authorization Domain

element in MOF structure

Get roles as a security principal in XML structures

Get roles as an attribute in ASN structures

RBAC Policies

XML-Based Web Service Authorization

Domain

Certificate-based Authorization Domain

53

Role Engineering


Role Engineering

10

Engineering approach

RoleEngineering

RBAC SystemDesign

RBAC SystemImplementation

RBAC SystemTest &

Integration

RBAC System Development

ImplementationDependent

Mappings onPhysical objects

R

ROLES

PERMISSIONASSIGNMENT

(PA)

P

PERMISS-IONS

Files/Directoris

Devices

Applications

OSs

...

Abstraction Layers(tasks, scenarios, …)

...

Role Engineering Approach

55

Engineering problem

• Separation of duties, lease privilege, …• Employee data, screening, …• e-Procurement system, ERP, …• …

• Separation of duties, lease privilege, …• Employee data, screening, …• e-Procurement system, ERP, …• …

Information Security Group

Analyzing, mapping, and refining semantics of purchasing manager role

Analyzing, mapping, and refining semantics of purchasing manager role

Purchasing manager role

System Administrator GroupHR department

Artifacts, data, …

56

Engineering schemesTop‐downBottom‐upHybrid

Security Administration

Roles

Top-down Bottom-upEach has its own advantages and pitfalls depending upon the varying contexts.

Top‐down: usually ignore existing permissionsBottom‐up: possibly ignore business functions within an organizationSystem Administration

Permissions

Top-downModel

Bottom-upModel

HybridModel

57

Top‐down scheme

Scheme where permissions are derived from roles

Use of abstract concepts


RoleDefinition

Top-down psuch as work‐pattern and business processesThe abstract concepts are analyzed and decomposed into functionally smaller units

System Administration

PermissionMapping

Top-downModel

58

Bottom‐up scheme

Scheme where permissions works as building blocks to compose roles


RoleComposition

Use of abstraction such as scenarios and business functions, or certain attributes of objects or operations

System Administration

PermissionDerivation

Bottom-upModel

59

Role mining

60

11

Role mining

61

Project Guideline: An Example


Project Guideline: An Example

EEnvironment/Domain Access Control RRequirementsAccess Control MModel System AArchitecture

Typical Approach

63

System AArchitectureImplementation through MMechanisms

Agenda

Discuss how “ERMPAM” can be materializedE: Distributed environment

R: Access control issues

M: Role‐based access control

64

A: Privilege Management Infrastructure

M: Feasibility test through COTS technologies

InternetAllow anyone to access

Environment

65

E-Business Services

Extranet

IntranetAllow only the people in an organization to access

Allow selected outsiders, customers or partners, to access

access

A uth enticatio n

A utho rizat io n

A p p licatio n serve r A p p licatio n serve r

E m ail S C MH R E R P C R M

EE AA MM ss yy ss tt ee mm

EE nn ttee rr pp rr iiss ee AA pp pp ll iicc aa tt iioo nn

ss ee rr vv ee rr ss

EE nn tt ee rr pp rr iiss ee AA pp pp ll iicc aa tt iioo nn ss

Authentication

Authorization

Extranet users

EAM SystemEAM System

Access request Security Credentials

Integrity /Interoperability

Environment ‐ EAM

66

A uth enticatio n

A utho rizat io n

A p p licatio n serve r A p p licatio n serve r

E m ail S C MH R E R P C R M

EE nn tt ee rr pp rr iiss ee BB oo uu nn dd aa rr yy

EE AA MM ss yy ss tt ee mm

EE nn ttee rr pp rr iiss ee AA pp pp ll iicc aa tt iioo nn

ss ee rr vv ee rr ss

EE nn tt ee rr pp rr iiss ee AA pp pp ll iicc aa tt iioo nn ss

EE nn tt ee rr pp rr iiss ee BB oo uu nn dd aa rr yy

Application serverApplication server Application serverApplication server

EmailEmail SCMSCMHRHR ERPERP CRMCRM

Enterprise BoundaryEnterprise Boundary

Enterprise Enterprise Application Application

ServersServers

Enterprise Enterprise ApplicationApplication

ss

Granting Access

Security Credentials

EAM (Extranet Access Management): a unified mechanism that enables network administrators to manage authentication and authorization of users across enterprises – Source: Gartner Research, 2001.

12




Agenda

67



From closed to open environmentThe Internet technologies have been replacing traditional business processes with web‐based business solutions

Administrative complexity and blurring boundaries

Access Control Issues

68

Recent trends in web‐based solutions increase the administrative complexity of access management and blurs enterprise boundaries.

Lack of support for interoperabilityEAM was considered as a possible solution, but its authorization still needs to be investigated, especially in terms of interoperability.

Centralized administrationAll application servers are dependant on Access Control (AC) ServerAC Server specifies roles and its permissions

h l l

AC Requirement

69

Coherent access control policyRole‐specification and role‐assignment policies are managed in AC ServerA change of access control policy in one place can propagate through distributed components in the domainOne Access Control Policy in AC Server will govern the entire domain

Architectural Requirement

AC Server – Trusted Third PartyAll components in the domain trust the AC ServerManagement of trust relationship is easier and more secure

Integrity of User Information

70

Sensitive user’s personal information is restrained in AC ServerRegistration in one place and access everywhere will provide integrity of user information

Users’ PrivacyLeast users information required for access control is revealed to application server

Need a Model: RBAC

Need to make access control decisions on “the roles that individual users take on as part of the organization”Need to centrally control and manage access rights based on the organization’s security policy

71

Need to provide application independent access control policy




Agenda

72



13

Least privilegeOnly those permissions required for the tasks performed by the user in the role are assigned to the role

Separation of duties

Why RBAC

73

pInvocation of mutually exclusive roles can be required to complete a sensitive task

Data abstractionInstead of the read, write, execute permissions typically provided by the operating system, abstract permissions can be established




Agenda

74



PMI MODELS

Control Model

Environmental

Variables Object Method

Roles Model

Role assignment

Delegation Model

Source of AuthPMI MODELS

Optional Model

75

AT T R I B U T E CE R T I F I C A T E FR A M E W O R K

Role Group Clearance Audit Identity

General Model

Object Privilege asserter Privilege verifier

Role assignment Role specification

Source of Auth. Attribute Auth.

PMI MODELS

Possible Attributes Possible Attributes

Public Key Certificate (PKC)Public Key Certificate (PKC) Attribute Certificate (AC)Attribute Certificate (AC)

VersionVersion VersionVersion

Serial NumberSerial Number

Signature IDSignature ID



Attribute Certificate (AC)

76

SubjectSubject

IssuerIssuer

Validity PeriodValidity Period

Subject Public Key InfoSubject Public Key Info

ExtensionsExtensions

Algorithm IDAlgorithm ID

SignatureSignature

HolderHolder

IssuerIssuer


AttributesAttributes

ExtensionsExtensions

Algorithm IDAlgorithm ID

SignatureSignature

Why PMI?

Essential requirement is authorization not authenticationX.509 Public Key Certificate provides authentication service based on PKIMore important to know what a user can do than who a user is

ff l l f

77

Difficult to manage privilege information in PKIComplicated issuing process including user identificationIn general validity of privilege is much shorter

Identity certificate is passport and AC is visaNeed to integrate PKI with PMI

How1. Need two different attribute certificates based upon

PMI roles model.Role assignment attribute certificate (RAAC): assigning roles to a userRole specification attribute certificate (RSAC): assign permissions to a role

78

2. Need to identify and design role administration components to manage RBAC policies in a systematic and efficient manner.

3. Need to investigate possible system architectures so that we can fully utilize attribute certificate.

14

Role Specification ACRole Specification ACRole Assignment ACRole Assignment AC

VersionVersion



VersionVersion



Two Attribute Certificates

79

SignatureSignature SignatureSignature


RoleRole

IssuerIssuer


PermissionsPermissions


HolderHolder

IssuerIssuer


RolesRoles

Attribute Certificate Role Engineering

Role Database Role engineering

Request/issue RAAC

Issue certificates

PMI Attribute AuthorityPrivilege Asserter

Retrieve role information

System Architecture

80

Server

Access Control Policy Server

Server

Client

Policy Database

Request/issue RSAC

Store attribute certificates

Setup access control policy (RSAC)

AC Storage

Access request with RAAC

Return access request result

Privilege Verifier

• Server – Enhanced Performance (+)• AC Management in client (-)• Complicated Client-Server Protocol (-)

Issue

AC Server

Push Model

81

Access ControlDecision Making

Access Request with AC

Issue Attribute

Certificate

Application Protocol based on AC

Client ApplicationServer

• Increase Server Overhead (-)• simple client module (+)• Simple modification in existing Client-Server Protocol (+)

ObtainAttribute

Certificate

AC Server

Pull Model

82

Application ProtocolWithout AC

Access ControlDecision MakingClient Application

Server

• A set of roles and permissions is defined according to Role-Based Access Control Policy• Application Server requests an AC with a predefined role

AC Server issues the AC that

AC Server

Role Specification

83

• AC Server issues the AC that contains the provided role• Centralized Access Control Policy Administration in a distributed environment• RBAC Policy is stored in LDAP or internal database

Role-SpecificationAC Request

Access ControlPolicy Server

Ldap Server

A client is assigned to a specific role

AC Server

Role Assignment

84

• A client is assigned to a specific role• When a client request a AC, AC Server issues a role-assignment AC• RAAC contains the assigned role that a client can use to access an application server

Role-AssignmentAC Request

Client

15

Access Request

Access ControlPolicy Server

Access Granted

Decision Making Engine

85

RBAC Decision Making Engine

DecisionRequest

DecisionResponseRAAC

Web ApplicationServerClient

Access PolicyStorage




Agenda

86

P: Attribute certificate

A: Pull and Push architecture


X.509 AC Manager

87

Role Administration Tool

88

ConclusionsShowed how distributed networked environments can support scalable access control policies First attempt to accommodate PMI roles modelIntroduced systematic role engineering and system architecture

89

architectureDemonstrated the feasibility of proposed approach through a proof‐of‐concept prototype implementation

a question… cs489/589: access control & system securitydoshin/t/s10/cs589/docs/note3.pdf ·...

Documents