1 / 22

Role-Based Access Control on the Internet

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,”

anisa
Télécharger la présentation

Role-Based Access Control on the Internet

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 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. COMSAC’02.

  2. Motivation • Information is Everywhere • Need Tools to Control Access to Information • Existing Access Control Models Don’t 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/Can’t 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 Doesn’t 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 User’s 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 User’s Password Encrypted With Web Server’s 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 User’s 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 Server’s Public Key

  12. 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 My Pros/Cons of User-Pull Architectures

  13. Server –Pull Architectures • Users Authenticate Themselves to Web Server • Web Server Obtains User’s Role From Role Server • Users Make Request to Web Server • Web Server Grants Access Based on the User’s 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 User’s 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 client’s role information to DS 6 LDAP over SSL; Return client’s 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. 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 My Pros/Cons of Server-Pull Architectures

  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

More Related