Role-based authentication framework for enterprise

Vishal Kher

Yongdae Kim

Friday, November 19, 2004

2

Outline Motivation Role-based authentication framework

– Requirements– Assumptions– Schemes

Related work Implementation Plans

3

A Simple Enterprise

How to provide authentication and access control across multiple servers?

Admins. need to maintain this info. for individual servers– Too cumbersome and difficult– Prone to errors– Unnecessary repetition of work

Network

File server

File serverDatabase server

4

Managing multiple systems is hard In an organization, users require access to

multiple systems– File servers, Data base servers, travel/retirement

accounts These systems require some form authentication

and authorization This information can get updated independently

– Hard to maintain consistency across multiple systems

System independent authentication and authorization

operations

5

Who should access the data? In an enterprise, end users do not ``own'' data

– Access decisions based on user’s job function or “role”

– Role-based access control (RBAC) uses this fact Role is a set of transactions

– Transaction (operation) is unit of control – r/w, search, deposit, withdraw, accept proposals

Permissions are assigned to “Roles”– Member enjoys the privileges assigned to the role

Role Membership can change frequently– Typically roles do not change frequently

Roles and permissions can be inherited or constrained

6

RBAC Continued Requires thorough analysis and policy decisions

– Depends on an organization– Once framework is set-up administrative task is to

assign user’s to roles Advantages

– Ease of management and reduce cost of administration

– Less errors– Can describe complex access control policies

Implementation– Sun Solaris 8.0, Oracle 9iAS– Web server for UNIX and NT - NIST

Recently, NIST proposed RBAC standard

7

Whats in it for me?

How can a user acquire his roles?

How can a user prove his roles?

How can a system administrator revoke a user and/or user’s roles?

8

Current Storage Servers Heavily based on UNIX-style UID and GID

– Access decisions are primarily based on UID/GIDs– File ACL: user/group/other

Perils of UID/GID style access control– How to maintain a global UID/ GID mapping?– How to find all files associated with a particular UID?– Difficult to maintain and administer this information

Backups– Data is long-lived– What if the UID/GID doesn’t exist while restoring old

backed-up data• root has to recover the data• But the data doesn’t really belong to root

9

The Final Theme

Efficiently use RBAC authentication framework– Can be combination of capability and identity

credentials

Free servers from the bondage of UID/GID style access control

File access based on roles – Change file access semantics from UID/GID to

roles only

10

Related Work Kerberos and other 3-party protocols

– No notion of roles/groups– Cannot specify constraints on the roles– Sometimes RBAC needs support for authorization

• Mixture of access permissions as well as list of roles

Most of the other schemes use public keys– Use extension field of X.509 v3 (list roles)– X.509 attribute certificate (ACL in certificate)– Not appropriate for high performance applications

• File servers, HPC• High client-side latency and high load on the file servers

– Use symmetric key techniques

11

Outline Motivation Related work Role-based authentication framework

– Requirements– Assumptions– Scheme

Implementation Plans

12

Applying Role-based Policies

Central Policy Manager (Aura) determines policies– User – role assignment– Role – permission assignment– Revocation and other management activities

Other servers implement these policies– Data access based on roles

Network

Servers

Aura

13

Requirements Role membership and policies should be

maintained by a central entity – Entity should be different from local admins.

Clients should get appropriate roles and should be able to prove his/her roles

Client – Server Mutual authentication– Authentication based on symmetric keys

Efficient revocation mechanism File access should be based on roles

14

System Assumptions Aura is a trusted entity Clients are not trusted

– Can perform all kinds of active/ passive attacks Server – client communication link is insecure

– No underlying security protocol such as IPSec Aura can communicate securely with clients Servers are trusted to play their role

appropriately

15

System Setting

Aura

File server

rNurse

rwDoctor

RightsRole

Doctor

Surgeon

[…]

Alice

RoleUser

K

K

Get role

key

Role Key =

H K(ro

leList)

M, MACroleKey(M)

R, MACroleKey(R)

16

Protocol Details (1)

Setup– Aura and server share K

Generation of role key– roleKeyc=MACK(Ic,H(roleList),expiry,[..])

• Ic = Identity of client C

• roleList = list of all roles of the client• expiry = validity period of the role key• [..] = constraints and other stuff

Securely transfer roleKeyc to the client– A C: roleKeyc, roleList, expiry

17

Protocol Details (2)

Freshness –

– C S: M, MACroleKeyc(M)

• M=Req,Ic,roleList,expiry,currentRole,r

– S C: M={Resp, r, s}, MACroleKeyc(M)

18

Protocol Details (3) C S: M, MACroleKeyc

(M)– M = {Opr, Oid, Ic, roleList, expiry, currentRole, r, s}

Server– Checks if currentRole is present in roleList– Generates roleKeyc

• from K,Ic,roleList,expiry

– Verifies MACroleKeyc(M)and freshness

– grants access rights according to the RBACL stored

S C: M, MACroleKeyc(M)

– M = {Response, r, s}

19

Revocation Revocation of client

– Expiry field in roleKey– Revocation list

• File manager can push it to devices• Devices can pull periodically using LDAP

Client’s role– This information can be include in revocation list– Include an expiry field with roles in the roleKey

20

Revocation (Contd.) Revocation of entire role

– This information can be include in revocation list Changes to RBACL

– Store an object per role on the device• Doubly linked pointer to all objects accessed by the role

– Advantage• Faster lookup

– Disadvantage• Space• Frequent updates of this object

21

Advangates Centralized revocation and management Simple role-based authentication Direct access to servers after acquiring initial

roleKeys – No public key operations on data path

Free from the UID problem

22

Implementation Plans (1)

NFS with ext3

LDAP

Instant revocation

Periodic download

Open {UID = random,

GID = H(rolename)}

NFS

??

1. Password

2. Public key

23

Implementation Plans (2) Main challenge

– Getting rid of UID/GID Format for roleKeys How to map role to some id?

– Hash of role name?– Unique global and permanent id

Change NFS RPCs to modify access semantics Role-based access control list

– Linux ext3 extended attributes

24

Thank You

Suggestions?