Web Services: Role Based Access Control with Single Sign-on Architecture

Rochester Institute of Technology Department of Computer Science M.S. Computer Science Project Proposal Web Services: Role Based Access Control with Single Sign-on Architecture Yevgeniy Gershteyn gershteyn@gmail.com Committee: Dr. Leon Reznik, Chair James Kwon, Reader TBD, Observer Rochester, NY February 18, 2008

Revision History Date Version Description Approval 12/18/2008 0.01 Initial --- 02/18/2008 0.02 Version 1 2

Table of Contents 1 INTRODUCTION... 4 1.1 PROJECT OBJECTIVE... 5 2 BACKGROUND... 6 2.1 ROLE BASED ACCESS CONTROL... 6 2.1.1 NIST RBAC Model... 7 2.2 SINGLE SIGN-ON... 10 2.2.1 Single sign-on in In-VIGO: role-based access via delegation mechanisms using short-lived user identities... 11 2.2.2 PASS: A privacy-friendly, secure and open Single Sign-On Protocol for Web Services... 12 3 APPLICATION FUNCTIONAL SPECIFICATION... 15 3.1 SINGLE SIGN-ON APPROACH... 15 3.1.1 Use Case Diagram... 15 3.1.2 Use Case Diagram Description... 16 3.1.3 Entity-Relational Diagram... 17 3.1.4 Entity-Relational Diagram Description... 18 4 PRINCIPAL DELIVERABLES... 19 4.1 MS PROJECT REPORT... 19 4.2 Deployment... 19 5 PROJECT SCHEDULE... 20 5.1 CURRENT STATUS... 20 ANNOTATED REFERENCES... 21 Table of Figures Figure 1. NIST RBAC Model [3]... 8 Figure 2. High-level view of In-VIGO architecture [4]... 12 Figure 3.Use Case Diagram... 15 Figure 4. Entity Relational Diagram... 17 3

Web Services: Role Based Access Control with Single Sign-on Architecture 1 Introduction In a Modern World, Web Services have been widely used by different industries to improve the business s functions and productivity, integrate and automate their customer support, etc. Hence, it is essential to protect the information and all other resources from unauthorized access by controlling the access via a particular system. Nowadays, large organizations are also switching theirs activities from host-based application platforms to network-distributed, client-server platforms that brings some difficulties for both: endusers, who have multiple electronic identities for different systems, and for system administrators. Role-Based Access Control (RBAC) is a fairly novel access control technique that provides a centralized, dynamic, and consistent authorization management specifically for the requirements of a particular industry to improve its security. Since RBAC has been widely used as an approach to access control, in [1] the standard for RBAC, which includes the RBAC Reference Model and the RBAC Functional Specification, was proposed to support the research and development of software applications for such systems. Since an authentication mechanism is required for personalized, passwordprotected user s accounts, Single Sign-on (SSO) systems can provide authentication across different services. SSO is an access control mechanism that authenticates and authorizes a user into various software systems based on the user s permissions, and reduces extra logins when the user switches applications within one session [4, 5, 6]. Because of these benefits, SSO is an approach to implement the RBAC enabled system. Different RBAC models have been introduced and published in [1, 2, 3], and several RBAC systems has been designed and implemented in [7, 8]. SSO was exercised by different research institutions and commercial software makers. Well-known examples of SSO are In-VIGO (In-Virtual Information Grid Organization) [4], PASS (Privacy 4

Aware Single Sign-on) [5], and Microsoft Passport [9]. Though, there is no standardized way to proceed with SSO implementation. 1.1 Project Objective The primary objectives of this project are to determine how well RBAC can be implemented with SSO architecture using latest Microsoft.NET Framework. In this project I will develop the Web Portal with RBAC-based Member Services application to manage applications, users, and user s roles. As an example of SSO approach I will implement Scheduling System with User and Admin applications. The Scheduling Admin application will have options to setup different calendars with its own settings, and Scheduling User application will give an access to the calendars based on user s role. After the successful login, the user will be able to access different applications based on the role and role s permissions. This solution will have sharable control that will allow adding more applications as plug-in-play component. I will use latest Microsoft technologies, such as Microsoft.NET Framework 3.5, Windows Communication Foundation. The user interface and supporting features will be put into the service using C#, ASP.NET 2.0, and ADO.NET. The Portal will be deployed on Windows 2003 R2 Server with Microsoft SQL Server 2005. 5

2 Background This section overviews the fundamentals, characteristics, benefits, the NIST Standards, and existing models of RBAC. Also, it describes the idea of SSO architecture and the benefits of using this design for the implementation of the RBAC Web-based system. 2.1 Role Based Access Control The basic idea of RBAC is to give permissions to the users indirectly by using roles which are assigned to a particular user. Thus, the user gets a role (or several roles), and then the role (or roles) gives him predefined permissions. The roles indirection is similar to groups in UNIX and other operating systems and privilege groupings in database management systems. Though, groups can include only users as their members, RBAC can contain collections of users, permissions, and other roles in a single access control model in terms of roles and role hierarchies, role activation, and constraints on user/role membership and role set activation [1]. RBAC controls the users access to information and system resources based on users activities in the system, and requires the roles identification in the system. Such a model is supposed to have a set of basics elements such as users, roles, permissions, operations, and objects, and relations between these elements [1]. A set of actions and responsibilities related to a particular activity can defined a role, then permissions to access objects are specified for roles, and afterward, users are assigned to appropriate roles. Organizations may require various numbers of roles and access rules. In most organizations roles are quite constant while users and tasks which are assigned to them can be impermanent, and reassignment is essential. So, RBAC is a most suitable approach to provide secure association and access, because RBAC provides a powerful mechanism for reducing the complexity, cost, and potential for error in assigning permissions to users within the organization [2]. Since RBAC has role hierarchies, where a given role can enclose all of the permissions of some other roles, it is a way to go for organizations where roles have overlapping permissions. 6

Also, RBAC provides authorization constraints, for the reason that roles must be constrained in their relations to users and permissions, and constraints are crucial to establish higher-level access control policies within an organization [1]. One of examples of constraints is the separation of duty, which prevents the possibility of frauds or errors by controlling user-role and role-permission assignments. Role hierarchies and constraints make RBAC to be policy-neutral, so it can suit different access control policies that is beneficial for organizations that have a wide range of security policies or need to modify their access control based on their needs. 2.1.1 NIST RBAC Model RBAC is known as an open-ended technology which can be implemented for simple as well as complex systems. Therefore, it is not supposed to be treated as a single model, because such a model would be too narrow or too broad, and would stand for one solution out of many. Because of this reason, the NIST standard, which defines the features required for an RBAC system, was proposed in [1]. It has two main components: the RBAC Reference Model and the RBAC Functional Specification [1]. The RBAC Reference Model provides a strict definition of RBAC sets and relations and intends to define a common vocabulary of terms for use in the prespecified requirements and to set the scope of the RBAC uniformed features. The RBAC Functional Specification introduces administrative, review, and system functions [1]. Administrative functions provide the ability to create, delete, and maintain RBAC elements and relations. As well as review functions offer the capability to perform query operations on RBAC elements and relations. And finally, system functions support the management of RBAC attributes on user sessions and making access control decisions. The NIST RBAC model consists of four model components: core RBAC, hierarchical RBAC, static separation of duty (SSD) relations, and dynamic separation of duty (DSD) relations (Figure 1). Core RBAC has a minimal set of elements and relations to satisfy the requirements of current RBAC systems. The elements of core RBAC are users, roles, permissions, and sessions, and user-role assignment and permission-role 7

assignment are relations which are fundamental in any RBAC system [1] (Figure1). Role activation in core RBAC is a part of user s session within a computer system. In core RBAC the administrative functions contain adding and deleting users from the set of users and roles from the set of roles, creating and deleting instances of user-to-role and permission-to-role assignment. The supporting system functions allow creating a user session with a default set of active roles, adding an active role to a session, deleting a role from a session, and checking if particular session has permission to perform a request operation on system resources. The review functions permit an administrator to view all the elements of the model and their relations, including users, roles, user assignments, role assignments, and session elements [3]. Core RBAC component is required in any RBAC system, but the other components of the model are independent of each other and can be implemented separately. Figure 1. NIST RBAC Model [3] The Hierarchical RBAC component of NIST (Figure 1) provides relations to support the concept of role hierarchies, i.e. an inheritance relation between roles. Role r1 is a descendant of r2 only if all permissions of r2 are also permissions of r1, and all users of r1 are also users of r2 [1]. Hierarchical RBAC introduces the concept of a role's set of authorized users and authorized permissions, and defines two types of role hierarchies: general and limited. General role hierarchies support multiple inheritance, 8

where a role may inherit permissions from multiple subordinate roles, and more than one role can inherit from the same subordinate role [3]. Limited role hierarchies enforce roles restrictions ensuring in a simpler tree structure, namely a role may have one or more immediate ascendants, but is restricted to a single immediate descendant [3]. The inheritance property significantly simplifies the identification of permission relationships. Roles are allowed permissions overlapping, where members of different roles may share permissions. Nowadays, in a corporate environment, many employees share common responsibilities, and to avoid multiple role definitions with similar permissions, role hierarchies are used. General role hierarchies are used to provide practical tools to build rules in such environment, and limited role hierarchies are simpler to implement, but still provide the hierarchical RBAC functionalities for roles. Four new administrative functions of hierarchical RBAC extend core RBAC: adding a new and deleting existing immediate inheritance relationship between two existing roles, and creating a new role and adding it as an immediate ascendant of an existing role and/or immediate descendant of an existing relationship. The review functions allow the administrator to view the permissions and users associated with each role either directly or by inheritance [3]. Constraints in NIST RBAC model are offered by SSD and DSD components (Figure 1), and used in organizations to enforce conflict of interest policies and prevent users possibilities to exceed the level of authority for their status. SSD enables exclusivity relations between roles according to user assignments, that is, no user can be simultaneously assigned to both roles in SSD [1]. SSD relations reduce the number of potential permissions to a user by holding a cardinality constraint on the users for a set of two or more roles, where cardinality is a number greater than one identifying a combination of roles that would abuse the SSD policy. So, briefly saying, the SSD is a collection of pairs (role set, n), where n 2 and no user is assigned to n or more roles from the role set [1]. In SSD the administrative functions include creating and deleting role sets and adding and deleting role members, and the review functions permit an administrator to view the properties of existing SSD sets. In the same manner, DSD relations (Figure 1) limit the possible permissions to a user by placing constraints on the roles that can be activated for a user s sessions. 9

Constraints in DSD are a collection of pairs (role set, n), where n 2 and no user session may activate n or more roles from the role set [1]. Also, DSD holds the property of least privilege, where, based on the role being performed, each user has different permission s levels at different times, and they do not exceed the time frame that they require to complete the job. The administrative and review functions in DSD are similar to SSD s functions, and let an administrator define and view DSD relations. The main advantage of the NIST standard is that the RBAC System and Administrative Functional Specification provides a functional benchmark for vendors, indicating which capabilities must be provided to the user and the general programming interface for those functions [3]. Also, the specification gives users particular standards for a documentation of requirements and evaluating products, and leaves room to build enhanced features. 2.2 Single Sign-on SSO is an access control mechanism that provides authentication of user s access across multiple software systems and different services based on the user s permissions, while reduces extra logins when the user switches applications within one session [4, 5, 6]. SSO has essential benefits for organizations with standardized infrastructure and centralized users database where single user entity authentication is critical. Different SSO approaches have been introduced by research community [4, 5], and designed and implemented by commercial software makers [9]. Still, it is challenging to build such a system since there is no standardized way to proceed with SSO implementation. On one side, each module of the system has to be aware how to receive and process authenticated call from a central location; but on the other hand, central location is supposed to know how to map application credential. The basic SSO system should contain the user database, optional cross reference table, session control mechanism, and web services, which allow all subsystems to obtain common information. Following subsections will overview two interesting SSO approaches which enrich basic SSO schema. The first one is In-VIGO (In-Virtual Information Grid Organization) system [4] with SSO approach for computational grids, 10

and the second one is PASS (Privacy Aware Single Sign-on) system [5] with enhanced privacy of the users profiles. 2.2.1 Single sign-on in In-VIGO: role-based access via delegation mechanisms using short-lived user identities This paper explains how SSO can be used to manage users within computational grids. The main idea of the In-VIGO approach is based on decoupling grid user accounts from local user accounts and using RBAC lists. The objective of this approach is to handle interactive applications and application-specific authentication mechanisms by using RBAC s delegation mechanisms and short-lived user identities [4]. Because grid properties cover administrative domains with independent authentication and authorization schemes and policies, SSO integrates grid users access to all authorized services and resources based on a single authentication that is done only ones, when they initially access the grid. SSO-enabled virtual grids grant a fully integrated access to authorized entities such as machines, data, applications, and networks based on the fact that in virtual grids all users resources as well as their information and computation requests have reside and been serviced on virtual entities following service s standards and requirements. This is a representation of RBAC, where In-VIGO principals who access entities are grouped into "roles", while "procedures" or "permissions" that describe access policies are defined on the entities, and permissions assigned to roles enable authorization [4]. The In-VIGO approach (Figure 2) puts three additional layers of virtualization on the typical grid computing model to hide details of lower layers implementation and allow gridwide operations. The first layer forms pools of virtual resources such as virtual machines, virtual data, virtual applications, and virtual networks to create a virtual computing grid. This layer decouples the procedure of distributing members of the virtual computing grid from physical hardware and software. The second layer encloses services, instances of grid applications, which can be linked as needed to create virtual information grids. This layer decouples the procedure of distributing services from grid applications. The third layer creates virtual interfaces to allow different access devices to display combined services, 11

which export their interfaces to users via portals. This layer decouples the process of creating services interfaces from the process of representing them on specific devices [4]. Figure 2. High-level view of In-VIGO architecture [4] Using SSO simplifies and enhances administrative control of all systems as well as users access across multiple systems, improves network security, and provides an ability to consolidate various systems. 2.2.2 PASS: A privacy-friendly, secure and open Single Sign-On Protocol for Web Services Nowadays, when an application s personalization becomes a very important feature, the implementation of SSO for these systems is increasingly difficult. In this case, user authentication has to be improved by adding personalization for each application within the SSO network or by providing common personalization options across the network. This paper discusses privacy, security, socio-economic, and technical issues along with the privacy aware SSO system and the user s preference personalization mostly for internet web applications. To implement such a system, it is crucial to have some type of cooperation across different services with common view of user preferences. All services 12

must agree on common profile, which move privacy to the most important property of SSO [5]. Privacy is very critical and vital piece of the internet accessible system which involves storage of the user information, such as real name and preferences. SSO system should give to the user the ability to specify which properties can be shared between the services and control data exchange as well as keeping all user data confidential from other sources. To remain it to be all confidential, the system should be designed with all latest security standards. Security is a key objective of SSO and should be relevant to the entire system by applying the best practices in authorization and authentication. Although a single point of security failure could be possible in the SSO system, it still gives the capability to manage user s access to the systems and specifically in RBAC Systems from one location. The implementation of the SSO system on the top of the existed applications is the tedious task. Everything needs to be accounted and combined from the existed systems to the new SSO administrative system. The functional constraints of the systems must be seamlessly incorporated into the new system without adding new complex procedures for the users. To diminish the cost of the development cycle the SSO system is supposed to reuse the existing technologies [5]. Socio-economic issue can arise during the implementation of the SSO system, since sub systems may belong to other companies. The biggest one is a compliance to the legal terms of the original site. There are different rules and regulations regarding the data protection, the use of cryptographic technology, anonymous access to services, and business practices [5]. Since privacy is a crucial concern for PASS protocol, the user is supposed to have ability to control cross-reference user names, sharing of personal data and services. PASS protocol assumes that users and service providers are in a trusted relationship, which is difficult to achieve in the real world internet applications. While most of the web portals are using basic authentication and sending a password as a clear text, PASS improves the security of the protocol by issuing the X.509 client certificate based on the new private- 13

public key pair after the initial authentication request from the user. The private key and the certificate are stored on the user device for later reuse [5]. 14

3 Application Functional Specification User Management with SSO web application would predefine structure and principals for any web application which can be added to this SSO authorized application network as plug-n-play. As an example Scheduling application will be delivered as well. 3.1 Single Sign-on Approach This section will provide use case diagram and database Entity Relational Diagram (ERD) 3.1.1 Use Case Diagram Figure 3.Use Case Diagram 15

3.1.2 Use Case Diagram Description Role-Based Access Control System with Single Sign On approach is designed to simplify management of multiple Applications with common technique which allows adding them as plug-n-play. Actors: System Admin, System User(s). Pre-conditions: User must have valid user name and password created by administrator. Admin account should be created before system deployment. Post-conditions: User will be granted access to all permitted application with assigned roles Flow: 1. Login process to authenticate user to the system. Then user is authorized to assigned role and given access to allowed applications with role level access rights 2. Member Services (Admin) administrative module to manage all applications and user for the system. Member services module has User and Application subsystems. In long run limited Administrator can be assigned to a partial Member Services module access a. User Management subsystem to manage all users including application access managed via role based technique (RBAC) b. Application Management subsystem to manage applications to allow Single Sign On (SSO) access for the System Users. 3. Application Access (User) SSO Application should have unique roles (i.e. Administrator, Power User, User, etc.) with access to the Application items (i.e. calendar item, employee ID field, or other items needs to be hidden from some users).the Application Items are identified during the Application setup. The user will have personally assigned role for available application (higher role has preference over the multiple roles assigned) Note: Administrator can be assigned regular user role as well 16

3.1.3 Entity-Relational Diagram Figure 4. Entity Relational Diagram 17

3.1.4 Entity-Relational Diagram Description Typically E-R diagrams demonstrate the preliminary design of the database entities and relationships between them and are not tied to any technology. This diagram is a detailed, logical representation of the data for the SSO project. Entities: User representation of the user entity with its properties such as user id, user name, demographic and employment information. The user can have multiple Roles. The User can be extended to several types, such as Administrator, Power User, User, Auditor, and others with personalized roles. Role representation of the role entity with its properties such as id, name, descriptions. The role can have multiple users, applications, and/or role access Application representation of the application entity with its properties such as id, name, description, location, version, and status. The application can have Roles and Items. Item representation of the item entity and its properties such as id, name, description, and type. One item definition can be applied to multiple Applications Permission representation of the permission such as Read, Write, and Access. The permission is a property of the RoleAccess relation. 18

4 Principal Deliverables 4.1 MS Project Report The Project Report will contain Product Manual, Deployment Instructions, Troubleshooting Guide, and Source Code. 4.2 Deployment The application will be deployed on the Windows 2003 Server with IIS 6 and will be accessible via URL. 19

5 Project Schedule Currently, the high level design has been completed. The Data Access Objects and User Interface work will be considered in the next phases of the project. The following phases of the project are planned and scheduled as follow: Activity Proposed Completion Date Proposal (high-level design) March 1, 2008 Detailed design March 30, 2008 Implementation and Coding April 30, 2008 Testing May 15, 2008 Project Report May 31, 2008 5.1 Current Status The following activities are currently underway: Database - Design and implementation DAO layer Design and Implementation User Interface Design and Implementation 20

Annotated References [1] David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D.Richard Kuhn, and Ramaswamy Chandramouli, "Proposed NIST standard for role-based access control," ACM Transactions on Information and System Security, Vol. 4, No. 3, August 2001. [2] Gail-Joon Ahn and Ravi Sandhu, "Role-based authorization constraints specification," ACM Transactions on Information and System Security, Vol. 3, No. 4, November 2000. [3] William Stallings and Lawrie Brown, "Computer Security: Principles and Practice," Chapter 4: "Access Control," Prentice Hall, August 2007. [4] Sumalatha Adabala, Andréa Matsunaga, Maurício Tsugawa, Renato Figueiredo, and José A. B. Fortes, "Single sign-on in In-VIGO: role-based access via delegation mechanisms using short-lived user identities, " In Proceedings of the 18th IEEE International Parallel and Distributed Processing Symposium, pages 22b, Santa Fe, New Mexico, April 26-30, 2004 [5] Lars Brückner and Martin Mink, "PASS: A privacy-friendly, secure and open Single Sign-On Protocol for Web Services," Technical Report, Darmstadt University of Technology, IT Transfer Office (ITO), Germany, June 2003 [6] Marek Hatala, Timmy Eap, and Ashok Shah, "Federated security: lightweight security infrastructure for object repositories and Web services," IEEE Conference on Next Generation Web Services Practices (NWeSP'05), pages 287-298, Seoul, Korea, August 23-27, 2005. [7] Faranak Farzad, Eric Yu, and Patrick C. K. Hung, "Role-based access control requirements model with purpose extension," the 10th Workshop on Requirements Engineering, pages 207-216, Toronto, Canada, May 17-18, 2007. [8] Dongwan Shin, Gail-Joon Ahn, Sangrae Cho, and Seunghun Jin, "A role-based infrastructure management system: design and implementation," Concurrency and Computation: Practice & Experience, Vol. 16, No. 11, September 2004. [9] Windows Live ID (Microsoft Passport) - http://www.passport.net; http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/enus/passport_about.mspx 21