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 ( )
A Designated Center of Academic Excellence in Information Assurance Education by the National Security Agency
(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
ProductionEngineer 2
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
ProductionEngineer 1
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
A Designated Center of Academic Excellence in Information Assurance Education by the National Security Agency
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 Designated Center of Academic Excellence in Information Assurance Education by the National Security Agency
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
A Designated Center of Academic Excellence in Information Assurance Education by the National Security Agency
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
Security Administration
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
Security Administration
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
A Designated Center of Academic Excellence in Information Assurance Education by the National Security Agency
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
Discuss how “ERMPAM” can be materializedE: Distributed environment
R: Access control issues
M: Role‐based access control
Agenda
67
A: Privilege Management Infrastructure
M: Feasibility test through COTS technologies
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
Discuss how “ERMPAM” can be materializedE: Distributed environment
R: Access control issues
M: Role‐based access control
Agenda
72
A: Privilege Management Infrastructure
M: Feasibility test through COTS technologies
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
Discuss how “ERMPAM” can be materializedE: Distributed environment
R: Access control issues
M: Role‐based access control
Agenda
74
A: Privilege Management Infrastructure
M: Feasibility test through COTS technologies
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
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
Validity PeriodValidity Period
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
Serial NumberSerial Number
Signature IDSignature ID
VersionVersion
Serial NumberSerial Number
Signature IDSignature ID
Two Attribute Certificates
79
SignatureSignature SignatureSignature
Signature IDSignature ID
RoleRole
IssuerIssuer
Validity PeriodValidity Period
PermissionsPermissions
Signature IDSignature ID
HolderHolder
IssuerIssuer
Validity PeriodValidity Period
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
Discuss how “ERMPAM” can be materializedE: Distributed environment
R: Access control issues
M: Role‐based access control
Agenda
86
P: Attribute certificate
A: Pull and Push architecture
M: Feasibility test through COTS technologies
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