RoleBased Access Control on the Internet

1
Role-Based Access Control on the Internet
Seth Freeman Computer Science Engineering
Department The University of Connecticut Storrs,
Connecticut 06269-3155
Research Paper Review Ph.D. Exam on J. Park, R.
Sandhu, G. Ahn, Role-Based Access Control on the
Web, ACM Trans. On Information and System
Security, 4 (1), Feb. 2001 D. Shin, G. Ahn, J.
Park, An Application of Directory Service
Markup Language (DSML) for Role-Base Access
Control, Proc. of 26th Annual Intl. COMSAC02.
2
Motivation

• Information is Everywhere
• Need Tools to Control Access to Information
• Existing Access Control Models Dont Scale Well
• Discretionary Access Control - Puts Too Much
  Power in the Hands of the User
• Mandatory Access Control - Very Rigid in Terms of
  Allowable Permissions and Usage
• Role-based Access Control (RBAC) Addresses
  Scalability Issues
• RBAC Provides Intuitive Means of Defining
  Security Policy - Focus on User and Their Needs
• Question Can We Utilize Existing Internet
  Technologies to Enforce RBAC on the Web?

3
Overview of Remainder of Talk

• Role-based Access Control
• Players in the Architectures
• Research Issues of the Papers
• User-pull Architectures
• Smart Certificates
• Secure Cookies
• Server-pull Architectures
• LDAP
• DSML
• Comparisons
• My Analysis/Critiques of Papers
• Conclusions

4
Role-Based Access Control

• RBAC Identifies Various Interactions With an
  Application to Define a Set of Roles
• Each User Is Assigned to a Given Role
• Based on Their Role They Have Corresponding
  Permissions
• Objective of RBAC
• Provide a Customization of Permissions Based on
  Role
• Allow Users to Act in Different Roles (Only One
  Role at Any Time)
• When Permissions Associated With Role Change Then
  What the User Can/Cant Do is Impacted
• Less Alteration of User Privileges

5
Players in the Architectures

• People
• End User - Each Assigned a Role
• Role Administrator - Manage Security/Roles
• Client
• Web Browser to Access Application
• Servers
• Role Server Maintains User-Role Assignments
• Web Server - Provides Services to End User via
  his/her Web Browser

6
Research Issues of Papers

• Primary Focus of Authors
• Utilize Existing Internet Technologies to Support
  RBAC
• Compare Two Architectures (User/Server Pull) in
  Which User-Role Information is Obtained
• Main Research Issues
• Incorporate Security so Performance of Web
  Application, Client Access is not Impacted
• Minimal Impact on User User Doesnt Have to
  Know About the Particular Security Solution
• Fault Tolerance - Does System Remain Usable when
  Role Server and/or Web Server Fail?

7
User Pull Architectures

• Users Authenticate Themselves to Role Server
• Users Obtain Role(s) From Role Server/Store
  Locally
• Users Present Role to Web Servers Prior to
  Requests
• Users Utilize Role Information in Multiple Web
  Servers for Entire Lifetime of the Role
• Must Prevent Against Tampering of Role(s) Stored
  Locally

8
Smart Certificates

• Certificates are Used to Provide Authentication
• Smart Certificates Extend Certificates by Adding
  Attribute Info to Extension Fields
• Attributes Issued From Same Certificate Authority
  (CA) or Other Attribute Authorities(AA)
• Multiple AAs Can Store Attributes in Extension
  Fields
• Web Server Verifies Identity Info Before
  Attribute Info

9
User Pull Architecture Using Smart Certificates

• Users Authenticate Themselves to Role Server (CA)
  and Obtain Smart Certificate

• Users Create Secure Connection to Web Server,
  Then Present Smart Certificate

• User Requests Resource from Web Server, and Web
  Server Processes Request Based on Users Role

10
Secure Cookies

• Cookies Used to Maintain State Info. Between
  Successive Visits to Web Server
• Create a Set of Secure Cookies to Store User
  Info.
• Secure Cookies include
• Name, Role, IP, Passwd, Lifetime, Seal
• Users Authenticate Themselves to Role Server,
  Obtain Secure Cookies and Store Them Locally
• Need to Protect Them From User Modification
• Role Server Encrypts the Values in the
  Passwd_cookie and Seal_cookie
• Passwd_cookie Contains Users Password Encrypted
  With Web Servers Public Key
• Seal_cookie Contains Digital Signature of Role
  Server on the Contents of the Set of Cookies

11
Secure Cookie Verification

• Web Server Uses CGI Scripts to
• Perform User-authentication
• Check the Integrity of Cookies
• Obtain Users Role Information
• User Authentication by Comparing IP_address with
  IP_cookie and/or Password With Passwd_cookie
• Web Server Verifies Signature in the Seal_cookie
  With the Role Servers Public Key

12
My Pros/Cons of User-Pull Architectures

• Pros
• Web Server Not Slowed Down by Role Certification
• Users can Reuse Role Info on Successive Visits
  and in Multiple Sites
• Other Users Not Impacted by Security

• Cons
• Increased Functionality in Client Side Browser
• Potential for Role Server to Bottleneck
• Secure-Cookies Verification on Web Server Side -
  Overhead

13
Server Pull Architectures

• Users Authenticate Themselves to Web Server
• Web Server Obtains Users Role From Role Server
• Users Make Request to Web Server
• Web Server Grants Access Based on the Users Role

14
Lightweight Directory Access Protocol

• Directory Services Allow for Efficient Management
  of Enterprise-wide Information
• Directories Typically Contain User Info. and Also
  Store Information on Resources and Services
• LDAP Defines a Way to Query/Update Information in
  Directories
• Install LDAP Client Onto Web Server
• Web Server Obtains Users Role From LDAP Server
  (Role Server)
• Web Server and LDAP Server Communicate Over SSL
• Potential Problem If Firewall Exists Between Web
  Server and LDAP Server

15
Server-Pull Architecture Using LDAP

• 1 Authenticate client (using password/client
  certificate)
• 2 Display the initial page
• 3 Request resources by clicking a link
• 4 Establish SSL between DS and Web Server
• 5 LDAP over SSL Request clients role
  information to DS
• 6 LDAP over SSL Return clients role information
  to Web server
• 7 Display appropriate resources after
  authorization

16
Directory Services Markup Language

• DSML Allows XML-enabled Applications to
  Communicate With LDAP Servers
• Use of DSML Requires an Intermediate Server to
  Translate DSML Queries Into LDAP Queries
• Web Server Intermediate Server Exchange
  Requests/Responses in XML Over HTTP
• Solves Firewall Issue of Previous Model
• Server-pull Architecture Using DSML Adds
• DSML Gateway Server to Translates DSML to LDAP
• Role Administration Server to Maintain User-Role
  Mappings
• Access Control Enforcer to Performs Access
  Control Decisions

17
Server-Pull Architecture Using DSML
18
My Pros/Cons of Server-Pull Architectures

• Pros
• Role Server Interactions Simplified (Web Servers
  (100s) As Opposed to Users(10000s))
• Credentials Verified by Web Server Without User
  Interactions
• Simplified Role Update/Revocation

• Cons
• Increased Functionality in Web Server
• Potential for Web Server Performance to Degrade
• Requires Additional Software Installation on Web
  Server or a Separate Gateway Server

19
Comparisons by Authors

• User-pull Architectures are Less Convenient for
  the User, but They Facilitate Reusability of
  Roles
• Users Can Reuse Roles in Different Sessions and
  in Multiple Web Servers
• Better Suited for Applications in Which User
  Convenience is a Priority
• Server-pull Architectures Cause a Decrease in Web
  Server Performance, but Increases Role Freshness
• Users Always Obtain Their Most Recent Role
• Better Suited for Applications Where Dynamic Role
  Update is Important

20
My Analysis/Critiques of Papers

• Unclear Meaning of Comparison Criteria
• High/low - What Do These Mean? (Binary?)
• How to Measure User Convenience?
• Performance Benefits/Drawbacks on User-pull and
  Server-pull Architectures are Unclear
• Which Specific Applications to Use One Over
  Other?
• Their Architectures have Limited Support of
  Traditional RBAC Model Features
• Are Role Hierarchies Supported Within Role
  Server?
• How are Constraints Supported Across Client
  (Browser), Role Server, and Web Server?

21
My Analysis/Critiques of Papers

• Authors Do Not Provide Any Quantitative
  Assessment of the Performance
• They Implemented Most of Architectures
• What are the Actual Performance Numbers?
• Does Practice Match Intuition in Their
  Comparison?
• Authors Do Not Consider the Issues Related to
  Long-term Management of Roles
• How is Role-Revocation/update Handled in the
  User-pull Architecture?
• How is Delegation of Authority Handled in Each
  Architecture?

22
Conclusions

• Controlling Access to Information Will Always Be
  Essential to Organizations
• RBAC Will Be Increasingly be Used for Web-based
  Applications Because of Its Scalability and
  Ability to Represent Many Different Security
  Policies
• The Authors Successfully Use Common Technologies
  to Support RBAC Over the Internet
• Important Quantitative Assessments Were Left Out
  of Their Work
• More Work Need to Be Done to Develop Reliable and
  Efficient Architectures