The OM-AM Framework and Role-Based Access Control · 2018-09-27 · The OM-AM Framework and Role-Based Access Control Prof. Ravi Sandhu George Mason University . edu

The OM-AM Framework andRole-Based Access Control

Prof. Ravi SandhuGeorge Mason University

www.list.gmu.edu

2© Ravi Sandhu 2000

AUTHORIZATION, TRUST AND RISK

u Information security is fundamentallyabout managing l authorization andl trust

so as to manage risk


THE OM-AM WAY

ObjectivesModel

ArchitectureMechanism

What?

How?

Assurance


LAYERS AND LAYERS

u Multics ringsu Layered abstractionsu Waterfall modelu Network protocol stacksu OM-AM


OM-AM AND MANDATORY ACCESSCONTROL (MAC)

What?

How?

No information leakageLattices (Bell-LaPadula)

Security kernelSecurity labels

Assurance


OM-AM AND DISCRETIONARYACCESS CONTROL (DAC)

What?

How?

Owner-based discretionnumerousnumerous

ACLs, Capabilities, etc

Assurance


OM-AM AND ROLE-BASED ACCESSCONTROL (RBAC)

What?

How?

Policy neutralRBAC96

user-pull, server-pull, etc.certificates, tickets, PACs, etc.

Assurance

Role-Based Access ControlThe RBAC96 Model


ROLE-BASED ACCESSCONTROL (RBAC)

u A user’s permissions are determinedby the user’s rolesl rather than identity or clearancel roles can encode arbitrary attributes

u multi-facetedu ranges from very simple to very

sophisticated


RBAC SECURITYPRINCIPLES

u least privilegeu separation of dutiesu separation of administration and

accessu abstract operations


RBAC96IEEE Computer Feb. 1996

u Policy neutralu can be configured to do MAC

l roles simulate clearances (ESORICS 96)

u can be configured to do DACl roles simulate identity (RBAC98)


RBAC CONUNDRUM

u turn on all roles all the timeu turn on one role only at a timeu turn on a user-specified subset of

roles


RBAC96 FAMILY OFMODELS

RBAC0BASIC RBAC

RBAC3ROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS


RBAC0

ROLES

USER-ROLEASSIGNMENT

PERMISSION-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS


PERMISSIONS

u Primitive permissionsl read, write, append, execute

u Abstract permissionsl credit, debit, inquiry

u System permissionsl auditor, operator, back-up operator


USERS

u Users arel human beings orl other active agents

u Each individual should be known asexactly one user


RBAC1

ROLES

USER-ROLEASSIGNMENT


USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES


HIERARCHICAL ROLES

Health-Care Provider

Physician

Primary-CarePhysician

SpecialistPhysician


HIERARCHICAL ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer


PRIVATE ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer

HardwareEngineer’

SoftwareEngineer’


EXAMPLE ROLE HIERARCHY

Employee (E)

Engineering Department (ED)

Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1



Employee (E)


Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1



Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1



Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1


RBAC3

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS


CONSTRAINTS

u Mutually Exclusive Rolesl Static Exclusion: The same individual

can never hold both rolesl Dynamic Exclusion: The same

individual can never hold both roles inthe same context


CONSTRAINTS

u Mutually Exclusive Permissionsl Static Exclusion: The same role should

never be assigned both permissionsl Dynamic Exclusion: The same role can

never hold both permissions in thesame context


CONSTRAINTS

u Cardinality Constraints on User-RoleAssignmentl At most k users can belong to the rolel At least k users must belong to the rolel Exactly k users must belong to the role


CONSTRAINTS

u Cardinality Constraints onPermissions-Role Assignmentl At most k roles can get the permissionl At least k roles must get the permissionl Exactly k roles must get the permission

Administrative RBACARBAC97


SCALE AND RATE OFCHANGE

u roles: 100s or 1000su users: 1000s or 10,000s or moreu Frequent changes to

l user-role assignmentl permission-role assignment

u Less frequent changes forl role hierarchy


ADMINISTRATIVE RBAC

ROLES

USERS

PERMISSIONS

...

ADMINROLES

ADMINPERMISSIONS

CAN-MANAGE


ARBAC97 DECENTRALIZES

u user-role assignment (URA97)u permission-role assignment (PRA97)u role-role hierarchy

n groups or user-only roles (extend URA97)n abilities or permission-only roles (extend PRA97)n UP-roles or user-and-permission roles (RRA97)



Employee (E)


Project Lead 1(PL1)

Engineer 1(E1)

Production 1(P1)

Quality 1(Q1)

Director (DIR)

Project Lead 2(PL2)

Engineer 2(E2)

Production 2(P2)

Quality 2(Q2)

PROJECT 2PROJECT 1


EXAMPLE ADMINISTRATIVEROLE HIERARCHY

Senior Security Officer (SSO)

Department Security Officer (DSO)

Project SecurityOfficer 1 (PSO1)

Project SecurityOfficer 2 (PSO2)


URA97 GRANT MODEL:can-assign

ARole Prereq Role Role RangePSO1 ED [E1,PL1)PSO2 ED [E2,PL2)DSO ED (ED,DIR)SSO E [ED,ED]SSO ED (ED,DIR]


URA97 GRANT MODEL :can-assign

ARole Prereq Cond Role RangePSO1 ED [E1,E1]PSO1 ED & ¬ P1 [Q1,Q1]PSO1 ED & ¬ Q1 [P1,P1]PSO2 ED [E2,E2]PSO2 ED & ¬ P2 [Q2,Q2]PSO2 ED & ¬ Q2 [P2,P2]


URA97 REVOKE MODEL :can-revoke

ARole Role RangePSO1 [E1,PL1)PSO2 [E2,PL2)DSO (ED,DIR)SSO [ED,DIR]


URA97 REVOKE MODEL

u WEAK REVOCATIONl revokes explicit membership in a rolel independent of who did the assignment

u STRONG REVOCATIONl revokes explicit membership in a role and its

seniorsl authorized only if corresponding weak

revokes are authorized



u dual of user-role assignmentu can-assign-permission

can-revoke-permissionu weak revoke strong revoke (propagates down)


PERMISSION-ROLE ASSIGNMENTCAN-ASSIGN-PERMISSION

ARole Prereq Cond Role RangePSO1 PL1 [E1,PL1)PSO2 PL2 [E2,PL2)DSO E1 ∨∨ E2 [ED,ED]SSO PL1 ∨∨ PL2 [ED,ED]SSO ED [E,E]


PERMISSION-ROLE ASSIGNMENTCAN-REVOKE-PERMISSION

ARole Role RangePSO1 [E1,PL1]PSO2 [E2,PL2]DSO (ED,DIR)SSO [ED,DIR]


ARBAC97 DECENTRALIZES

u user-role assignment (URA97)u permission-role assignment (PRA97)u role-role hierarchy

n groups or user-only roles (extend URA97)n abilities or permission-only roles (extend PRA97)n UP-roles or user-and-permission roles (RRA97)


Range Definitions

Range

Create Range

Encap. Range

AuthorityRange

RBAC ARCHITECTURES



What?

How?



Assurance


CLASS I SYSTEMSENFORCEMENT ARCHITECTURE

Client Server


CLASS I SYSTEMSADMINISTRATION ARCHITECTURE

AdministrativeClient

Server2

Server1

ServerN

AuthorizationCenter


CLASS II SYSTEMSSERVER-PULL

Client Server

AuthorizationServer

AuthenticationServer


CLASS II SYSTEMSUSER-PULL

Client Server

AuthorizationServer



CLASS II SYSTEMSPROXY-BASED SYSTEMS

Client ServerProxy


AuthorizationServer


RBAC MECHANISMS

u These architectures can besupported by means ofl X.509 certificatesl Secure cookiesl Etc.

u Different links can be protected bydifferent means


Related Technologies

u Cookiesl in widespread current use for maintaining

state of HTTPl becoming standardl not secure

u Public-Key Certificates (X.509)l support security on the Web based on PKIl standardl simply, bind users to keysl have the ability to be extended


Cookies


Security Threats to Cookies

u Cookies are not securel No authenticationl No integrityl No confidentiality

u can be easily attacked byl Network Security Threatsl End-System Threatsl Cookie Harvesting Threats


Secure Cookies on the Web


A Set of Secure Cookies


How to Use Secure Cookies


X.509 Certificate

u Digitally signed by a certificate authorityl to confirm the information in the certificate

belongs to the holder of the correspondingprivate key

u Contentsl version, serial number, subject, validity period,

issuer, optional fields (v2)l subject’s public key and algorithm info.l extension fields (v3)l digital signature of CA

u Binding users to keysu Certificate Revocation List (CRL)


X.509 Certificate


Smart Certificates

u Short-Lived Lifetimel More secure

n typical validity period for X.509 is months(years)

n users may leave copies of the correspondingkeys behind

n the longer-lived certificates have a higherprobability of being attacked

l No Certificate Revocation List (CRL)n simple and less expensive PKI


Smart Certificates

u Containing Attributes Securelyl Web servers can use secure attributes for their

purposesl Each authority has independent control on the

corresponding informationn basic certificate (containing identity information)n each attribute can be added, changed, revoked, or re-

issued by the appropriate authority– e.g., role, credit card number, clearance, etc.

l Short-lived certificate can remove CRLs


Separate CAs in a Certificate


Smart Certificates

u Postdated Certificatesl The certificate becomes valid at some time in

the futurel possible to make a smart certificate valid for a

set of durationl supports convenience

u Confidentialityl Sensitive information can be

n encrypted in smart certificates– e.g. passwords, credit card numbers, etc.


A Smart Certificate


Applications of Smart Certificates

u On-Duty Controlu Compatible with X.509u User Authenticationu Electronic Transactionu Eliminating Single-Point Failureu Pay-per-Accessu Attribute-based Access Control



What?

How?



Assurance

Documents

The OM-AM Framework and Role-Based Access Control · 2018-09-27 · The OM-AM Framework and Role-Based Access Control Prof. Ravi Sandhu George Mason University . edu