1 / 24

Role-based authentication framework for enterprise

Role-based authentication framework for enterprise. Vishal Kher Yongdae Kim Friday, November 19, 2004. Outline. Motivation Role-based authentication framework Requirements Assumptions Schemes Related work Implementation Plans. A Simple Enterprise.

melvyn
Download Presentation

Role-based authentication framework for enterprise

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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 Database server File server Network File 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 Aura Network Servers

  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. User Role Alice Doctor Surgeon […] Get role key Role Key = HK(roleList) Role Rights Doctor rw M, MACroleKey(M) Nurse r R, MACroleKey(R) System Setting K Aura K File server

  16. Securely transfer roleKeyc to the client • A  C: roleKeyc, roleList, expiry 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

  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 • GeneratesroleKeyc • fromK,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. Password • Public key ?? Implementation Plans (1) LDAP Periodic download Instant revocation Open {UID = random, GID = H(rolename)} NFS NFS with ext3

  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?

More Related