the sap sybase sql anywhere role based access control demo · the sap sybase sql anywhere role...

The SAP Sybase SQL Anywhere Role Based Access Control Demo

THE SAP SYBASE SQL ANYWHERE ROLE BASED ACCESS CONTROL DEMO

2

TABLE OF CONTENTS

INTRODUCTION ............................................................................................................................................... 3

INSTALLATION INSTRUCTIONS .................................................................................................................... 3

System Requirements .............................................................................................................................................. 3

Installation ................................................................................................................................................................. 3

SCENARIOS ..................................................................................................................................................... 4

Scenario 1: Creating and Viewing Reports .......................................................................................................... 4

Walkthrough .............................................................................................................................................................. 5

Scenario 2: Delegating Administrative Rights Through Impersonation .........................................................10

Walkthrough ............................................................................................................................................................10

Scenario 3: Running Without a Super-User .......................................................................................................16

Walkthrough ............................................................................................................................................................16

APPENDICES ................................................................................................................................................. 20

Appendix A: Overview of Role Based Access Control .....................................................................................20

Appendix B: Application Functionality ..............................................................................................................21


3

INTRODUCTION

This demonstration shows the functionality of SQL Anywhere 16’s new Role Based Access Control (RBAC) using sample application scenarios. The RBAC has the advantage of providing very precise control over the types of database operations a user can and cannot do. It allows application developers to create solutions that offer various levels of security, depending on what the user needs to do. Typical applications that can benefit from the RBAC include customer relationship management, practice management, and solutions that generate analytic reports. For more information about the RBAC, refer to Appendix A; for documentation about using the demo application, refer to Appendix B, both at the end of this document. INSTALLATION INSTRUCTIONS

System Requirements

• SAP Sybase SQL Anywhere 16 or higher

• The demo application will run on both 32-bit and 64-bit Windows operating systems

• .NET Framework 3.5 Runtime or higher (available from Microsoft’s Web site) The demo application was tested under Windows XP (32-bit) and Windows 7 (32-bit and 64-bit). Installation

1. Extract the compressed archive SA16_RBAC_Demo-App.zip into a new folder. 2. Run the file RBACDemo.exe to launch the application.

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/20784541-bab4-3010-bda4-ebad245c7fbc


4

SCENARIOS

A series of applications scenarios are provided to help understand the use, functionality and benefits offered by Role Based Access Control. Scenario 1: Creating and Viewing Reports The General Manager (GM) of a retail franchise that sells clothes gives Robert Smith, an analyst, the task of creating a report view for the regional manager in Utah containing information about the employees in Utah including their names, departments, social security numbers and salaries. Given the sensitive nature of this information, the GM wants only the information of the employees from Utah to be viewable by the regional manager of that state. The following table summarizes the database users and roles corresponding to the different employees, along with their security access:

Database User/Role Name Corresponding Employee Security Access

GMUser General Manager Give analystRole privilege to create views and access to tables ‘Employees’ and ‘Departments’

RobertSmithUser Robert Smith Inherited from analystRole

analystRole A role specific for analysts Create views and query tables ‘Employees’ and ‘Departments’

UTRegMngrUser Regional Manager in Utah Query report view from Utah


5

Walkthrough

1. Execute the following 2 SQL statements while logged in as GMUser. You can type the statements or select them from the drop-down list box at the bottom:

a. GRANT SELECT ON Employees to analystRole b. GRANT SELECT ON Departments to analystRole

These two statements give anyone granted the role analystRole the permission to select data from the tables Employees and Departments respectively.

2. Grant analystRole the role SYS_CREATE_VIEW_ROLE (which allows it to create views) while logged in

as GMUser.


6

Previously, in SQL Anywhere 12 and earlier, a user needed to have the RESOURCE authority in order to be able to create views. It granted users the right to create not only views, but also other objects such as tables and procedures. In SQL Anywhere 16, however, the right to create different objects is more granular, so there are more controls over the rights given to users and roles.

3. Grant RobertSmithUser the role analystRole while logged in as GMUser:

4. Execute the following SQL statement while logged in as RobertSmithUser:

CREATE VIEW UTEmployeesReportView AS SELECT (Employees.GivenName + ' ' +

Employees.Surname) AS Name, Departments.DepartmentName,

Employees.SocialSecurityNumber, Employees.Salary FROM GROUPO.Employees,

GROUPO.Departments where Departments.DepartmentID = Employees.DepartmentID

AND Employees.State = 'UT'


7

This creates a view called UTEmployeesReportView that has the names, departments, social security numbers and salaries of all the employees in Utah.

5. Execute the following SQL statement while logged in as RobertSmithUser: CREATE TABLE sampleTable(col1 int, col2 int)

This statement fails because RobertSmithUser was granted the permission to create views, but not the permission to create tables or other objects. As mentioned previously, it would not be possible in SQL Anywhere 12 or earlier to grant a user the right to create only views without granting them the right to create all objects.

6. Execute the following SQL statement while logged in as GMUser:

GRANT SELECT ON RobertSmithUser.UTEmployeesReportView TO UTRegMngrUser WITH

GRANT OPTION


8

Granting SELECT on the table will allow UTRegMngrUser to view UTEmployeesReportView.

7. Execute the following SQL statement while logged in as RobertSmithUser:

CREATE VIEW NYEmployeesReportView AS SELECT (Employees.GivenName + ' ' +

Employees.Surname) AS Name, Departments.DepartmentName,

Employees.SocialSecurityNumber, Employees.Salary FROM GROUPO.Employees,

GROUPO.Departments where Departments.DepartmentID = Employees.DepartmentID

AND Employees.State = 'NY'

This creates a view called NYEmployeesReportView that has the names, departments, social security numbers and salaries of all the employees in New York.

8. Execute the following SQL Statement while logged in as UTRegMngrUser:

SELECT * from RobertSmithUser.UTEmployeesReportView


9

The query result is displayed because UTRegMngrUser can select data from this view.

9. Now execute the following SQL Statement while logged in as UTRegMngrUser:

SELECT * from RobertSmithUser.NYEmployeesReportView

Notice this query fails because UTRegMngrUser was not granted the right to view NYEmployeesReportView.

To summarize, the GM (GMUser) granted analystRole the privilege to select data from specific tables that had sensitive information. RobertSmithUser, a user granted the analystRole role, created the view UTEmployeesReportView using those tables. After granting user UTRegMngrUser the privilege to SELECT from UTEmployeesReportView, the user UTRegMngrUser displayed the view. This scenario shows the granularity of controls accorded to objects in the system. It allowed RobertSmithUser to only have access to view the pertinent information in the Employees and Departments tables without having access to other sensitive information.


10

Scenario 2: Delegating Administrative Rights Through Impersonation A procurement manager working in the German branch of an Insurance company is tasked with creating a table to track all the company cars rented out to the employees working in Germany. The table will hold information about the car, its model, the period it is rented for, and the person to whom it is issued. However, since the procurement manager is away for the week, the IT consultant is delegated the task of impersonating the procurement manager to create the table by the General Manager (GM). The following table summarizes the database users corresponding to the different employees, along with their security access:


GMUser General Manager Administer table creation and impersonation roles

GerProcUser Procurement manager in Germany Create tables

ITConsUser IT consultant Administer table creation role and impersonate GerProcUser

Walkthrough

1. Grant ITConsUser the following roles while logged in as GMUser::

a. SYS_CREATE_TABLE_ROLE (in the Admin Rights list only) b. SYS_SET_USER_ROLE

The role SYS_CREATE_TABLE_ROLE gives users the right to create tables for themselves. Previously, in SQL Anywhere 12 and earlier, a user needed to have RESOURCE authority in order to be able to create tables. It granted users the right to create not only tables, but also other objects such as views and procedures. It also gave users the permission to create objects for other users. In SQL Anywhere 16, however, the right to create different objects is more granular, so there are more controls


11

over the rights given to users and roles. Also, in SQL Anywhere 16, users like ITConsUser can be created who are delegated only administrative rights over roles, which wasn’t possible in earlier versions of SQL Anywhere.

SYS_SET_USER_ROLE is a role that allows a user to temporarily assume the roles of another user in order to perform operations (also known as impersonation), provided they already have the minimum required privileges to perform the task to begin with. In SQL Anywhere 12 and earlier, a user would have required the DBA authority in order to be able to imitate other users, giving them the authority to perform all operations in the database. In SQL Anywhere 16, a user only needs to have the SYS_SET_USER_ROLE role and all the roles and privileges of the impersonated user. This grants the user GerProcUser the permission to create tables for itself. Previously, in SQL Anywhere 12 and earlier, a user needed to have the RESOURCE authority in order to be able to create tables. It granted users the right to create not only tables, but also other objects such as views and procedures. It also gave users the permission to create objects for other users. In SQL Anywhere 16, however, the right to create different objects is more granular, so there are more controls over the rights given to users and roles.

2. Grant GerProcUser the following roles while logged in as ITConsUser:

a. SYS_CREATE_TABLE_ROLE b. SYS_CREATE_VIEW_ROLE


12

As explained before, SYS_CREATE_TABLE_ROLE is a role that gives users the right to create tables for themselves. ITConsUser is able to grant SYS_CREATE_TABLE_ROLE to GerProcUser because it has administrative rights over the role. However, since it wasn’t assigned administrative rights over SYS_CREATE_VIEW_ROLE, it was not able to grant the role to GerProcUser.

3. Execute the following SQL statements while logged in as ITConsUser. You can type the statements or

select them from the drop-down list box at the bottom.

a. SETUSER “GerProcUser” b. CREATE PROCEDURE proc1 AS SELECT * FROM SYSUSER c. CREATE TABLE GerRentalCars(id int, emp_name varchar(256), date_out

date, date_back date, description varchar(256))

d. INSERT INTO GerRentalCars values (4542,'Lukas Rebholz','2012-09-04','2013-09-01','Blue VW Passat 2011'), (4595,'Angela Eppstein',

'2012-08-12', '2014-01-23', 'Black Mercedes C-Klasse 2010'), (4621,

'Julia Hessler','2012-01-23','2012-10-21','White Audi A5 Coupe 2013')

e. SETUSER


13

This statement initiates a session in which all subsequent statements will be performed as GerProcUser.

In this statement, GerProcUser, impersonated by ITConsUser attempts to create a procedure, which fails since GerProcUser was granted the right to create tables but not procedures.


14

In this statement, GerProcUser creates a table to track company cars rented out to employees in Germany. The table consists of an ID number to track the transaction, the employee to whom the car was issued, the date the car was signed out, the date the car will be or was returned and the description of the car.

This statement inserts 3 car transactions into the table.


15

The last statement ends ITConsUser’s impersonation of GerProcUser.

4. Finally, execute the following SQL statement as GerProcUser to view the table that ITConsUser created

while impersonating GerProcUser: SELECT * from GerRentalCars

To summarize what was accomplished in this scenario, ITConsUser (administers table creation) impersonates GerProcUser (can create tables), who is away for the week, in order to create a table to track all the company cars rented out to employees in Germany. After inserting some records of transactions into the table, GerProcUser is able to view the table. We showed how in SQL Anywhere 16, users can be customized to be able to create tables while not necessarily being able to create all types of database objects, as was the case with earlier SQL Anywhere versions. We also demonstrated that the executive and administrative rights over roles can be delegated separately to different users and roles. This scenario once again demonstrates the flexibility obtained by SQL Anywhere 16’s more granular security features. It provides the ability to create users such as ITConsUser that have the ability to create tables and impersonate other users, but are not accorded administrative status. Users like ITConsUser don’t need the ability to manage other users, view sensitive information, or delete any objects.


16

Scenario 3: Running Without a Super-User This scenario shows that in SQL Anywhere 16, the database can be run without having an administrator user who is able to perform all privileged tasks in the system. A consumer electronics company needs a new role in their database for the employees working in the finance department. The IT consultant will create this new role and administer it in order to grant the role with administration rights to the manager of the finance department, Jennifer Irving. Jennifer will then be able to grant the role to all the employees in her department. The following table summarizes the database users corresponding to the different employees, along with their security access:


DBA General Manager Full access with exception to administration over FinanceDeptRole

ITConsUser IT consultant Create new roles and grant administration over the roles to JenniferIrvingUser

FinanceDeptRole A role specific for employees in the finance department

JenniferIrvingUser Jennifer Irving Inherits from FinanceDeptRole

Walkthrough

1. Grant ITConsUser the role SYS_MANAGE_ROLES_ROLE while logged in as DBA:


17

The role SYS_MANAGE_ROLES_ROLE allows users to create and delete roles. It also acts as a default administrator for newly created roles if the administrators of the new role are not specified during the role’s creation.

2. Create a new role called FinanceDeptRole while logged in as ITConsUser.

As mentioned in Appendix B (Application Functionality), creating a new role in this demo gives administration of that role to the user that was logged in when the role was created.

3. Grant JenniferIrvingUser the role FinanceDeptRole while logged in as DBA:


18

The operation fails because FinanceDeptRole was not granted to DBA. In SQL Anywhere 12 and earlier databases, you could create a super-user by granting them DBA authority. Users with DBA authority could perform any privileged task in the system. When you upgrade your database to SQL Anywhere 16, any users that had DBA authority obtain the SYS_AUTH_DBA_ROLE role, and automatically receive execution and administration rights for all roles and privileges that are present at the time of the upgrade. Also, when you create a new role and don't specify an administrator at creation time, users with the role SYS_MANAGE_ROLES_ROLE administer the role. However, if you create a new role and assign administrators as part of role creation, administration is then limited to the grantees that were given administration rights. Therefore, if you want a super-user to have administrative rights for the new role, you must grant it explicitly.

4. Grant JenniferIrvingUser the role FinanceDeptRole (both on Execute Rights and Admin Rights lists)

while logged in as ITConsUser:

JenniferIrvingUser will now be able to grant the FinanceDeptRole to all the employees working in her department.


19

To summarize, the General Manager granted SYS_MANAGE_ROLES_ROLE to ITConsUser in order to be able to create new roles in the system. ITConsUser then created the FinanceDeptRole (a role to be granted to all the employees in the finance department) and gave administration of the role to itself. The DBA then attempted and failed to grant the role to JenniferIrvingUser, the manager of the finance department. Finally, ITConsUser granted executive and administrative rights over FinanceDeptRole to JenniferIrvingUser.


20

APPENDICES

Appendix A: Overview of Role Based Access Control Prior to SQL Anywhere 16, the security model was based on authorities (the ability to perform tasks at the database level such as backups and tracing), permissions (the ability to create, modify, query, use, or delete database objects) and users/groups (have authorities and permissions attributed to them). In SQL Anywhere 16, the security management system has been reconfigured and is now based on Roles. Roles are a collection of privileges, other roles, or both. Granting roles to a user is equivalent to granting the user the underlying privileges therein. When granting a role to another user or role, you can choose to grant administrative rights to the grantee so that they can manage the role or grant it to other users. This allows you to create users who only have administrative rights over roles without being able to perform the privileges underneath the roles. The privileges available in a database are divided into system privileges and object-level privileges. A system privilege is a right to perform an authorized database task. For example, the SELECT ANY TABLE system privilege allows a user to query any table or view in the system. These system privileges correspond to pre-provided roles in the database that have the same name as the system privilege with ‘SYS’ at the beginning, ‘ROLE’ at the end and underscores between the spaces. For example, the system privilege CREATE TABLE corresponds to the role SYS_CREATE_TABLE_ROLE. An object-level privilege, on the other hand, is a right to perform an authorized task on a specific object. For example, having the INSERT privilege on a particular table allows a user to insert into that specific table, but not into other tables. Note that the authority based security model from earlier versions of SQL Anywhere is fully supported by SQL Anywhere 16’s Role Based Access Control. Existing applications can be upgraded to SQL Anywhere 16 without making any changes to the security model. To learn more about the Role Based Access Control in SQL Anywhere 16, visit the following link: http://dcx.sybase.com/index.html#sa160/en/dbadmin/da-roles-concept.html.


21

Appendix B: Application Functionality This section describes the functionality available in the demo application. Log in This drop-down list contains all the users in the database. The selected user will be the one logged into the database when any operation is executed against the database.

Users/Roles This drop-down list is used to select users or roles in the database in order to be altered.

Granting/Revoking Roles Lists all the roles in the system. The checked roles are the ones that are granted to the user or role selected in the “Users/Roles” drop-down list. The checked roles appear in the “Executive Rights” and “Admin Rights” lists. You can grant or revoke a role by checking and un-checking their box. By default, when granting a role, you also grant executive rights on that role. You can then choose to grant or revoke executive and administrative rights on granted roles by checking and un-checking the roles in the “Execute Rights” and “Admin Rights” lists respectively.

Deleting Roles This button deletes the user or role selected in the “Users/Roles” drop-down list.

Executing SQL Statements The bottom area is reserved for executing SQL statements against the database. You can type a SQL statement into the drop-box list box or select one already provided. The statement is executed by clicking on “Execute SQL Statement”, at which point the results of a successful SELECT query are displayed in a new window. All non-SELECT SQL statements open up a


22

dialog box indicating whether the execution of the statement was successful or not. Creating New Users/Roles Clicking the “Create New User/Role” button opens up a dialog where you can enter the name and type of the new user/role/user-extended role. Press the “Add” button to add this user/role. Creating a new role or user-extended role gives the currently logged in user the administrative rights to the role.

Resetting the Demo Use this button to erase all the new users/roles and database objects you created. Essentially, it resets the demo application to its initial state.

www.sap.com

© 2013 SAP AG or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary.

These materials are provided by SAP AG and its affiliated companies (“SAP Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Please see

http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark

for additional trademark information and notices.

the sap sybase sql anywhere role based access control demo · the sap sybase sql anywhere role...

Documents