ONE of the challenges we all face when developing

Transcription

1 Using SQL-DMO to Handle Security in ADPs Russell Sinclair Smart Access MSDE is a powerful, free version of SQL Server that you can make available to your users. In this issue, Russell Sinclair introduces you to SQL-DMO the SQL Server administrative programming library and shows you how you can put it to use by creating a security add-in for ADPs. ONE of the challenges we all face when developing Access Data Projects (ADPs) comes from the fact that we often work with MSDE. MSDE is the free version of SQL Server that can be distributed with your applications. Microsoft doesn t allow you to distribute its administrative tools with MSDE, so you must create your own interfaces to administer the application database. Fortunately, Microsoft does provide an object library that lets you programmatically administer SQL Server SQL Distributed Management Objects. SQL Distributed Management Objects, or SQL-DMO, provides programmatic access to virtually all of the administrative tools available in SQL Server. SQL-DMO is extremely powerful. I ve used it in the past for all sorts of purposes including creating backup/ restore tools, providing a tool for ing a SQL database to our technical support group, and even creating my own SQL Server object browser similar to the one in Enterprise Manager. When it comes to ADPs, one of the tools that I regularly need is something that allows me to configure object-level security within the SQL database. The tool I wanted to create needed to be reusable. I didn t want to have to copy objects between servers, databases, and projects every time I created a new database. In order to satisfy this condition, I chose to design the tool as an Access add-in. Using an add-in allowed me to create local Jet tables to store information needed in order to create the tool and to allow me to piggyback on an ADP s connection information in order to get to the server. Getting started In order to get started using SQL-DMO, you first need to add a reference to the object library. This library is included with most SQL Server installations, including MSDE. It s listed as Microsoft SQLDMO Object Library in the References dialog in the VBA IDE. If you re used to navigating SQL Server databases in Enterprise Manager (EM), the SQL-DMO object library will feel very familiar. The object library is quite extensive and is laid out in much the same way as you d navigate SQL Server objects in EM. There are two central objects in SQL-DMO that you need to know about in order to get started the Application object and the SQLServer object. The Application object is the central object in SQL-DMO, and you don t necessarily need to reference it it s implicitly created as necessary when you reference any SQL-DMO object. It can be used to access different servers, or to determine some of the information about the DMO library being used. The SQLServer object is probably the most important object in the SQL-DMO object library. This object refers to an instance of SQL Server. This object provides access to all other objects on a server. Collections on this object include Databases, Logins, and ServerRoles. This object also exposes methods to enumerate various objects and properties of the server and the objects that reside there. In order to access any server, you first need to connect to it using the SQLServer object. This can be done using the Connect method. The following code demonstrates connecting to the local server using SQL authentication: Dim sql As SQLDMO.SQLServer Set sql = New SQLDMO.SQLServer sql.loginsecure = False sql.connect "(local)", "sa", "MySAPassword" sql.disconnect The LoginSecure property of the SQLServer object specifies whether to use SQL authentication or Windows authentication (SQL = False, Windows = True). The default setting for this property is True. However, I like to set it explicitly so that the code can easily be changed or handle multiple connection situations. You can then connect to the SQLServer object using you guessed it the Connect method. This method takes three parameters: the server name, a user name, and a password. Unconnected SQLServer objects will generate an error if you try to access any of their methods or child objects. If you specify sql.loginsecure = True, the user name and password will be ignored by the Connect method. Once you re finished with a SQLServer object, it s imperative that you call the DisConnect method. Failure to do so will 8 Smart Access December

2 result in a connection being held open on the server even after your code finishes and the SQLServer object falls out of scope. Alternatively, you can call the Quit method of the Application object to disconnect all SQLServer objects in your code. In my add-in (available in this month s Download file at I used the CurrentProject.Connection.ConnectionString property in order to determine the connection information. This property returns all of the connection information necessary to connect to the database with the exception of the user s password (if using SQL authentication). Since I couldn t get the password from this string, I created a form (frmlogin in the sample database) that prompts the user for this information when using SQL Server authentication. There are numerous resources on the Web that can give you a full introduction to SQL-DMO. If you do a Google search on the words introduction SQL- DMO you ll get pages of links connecting you to introductions to the object model. MSDN, SQLTeam.com, SQLServerCentral.com, and many other Web sites have introductions to SQL-DMO that can get you started if you need more information. Since I have a particular goal in mind, I m going to jump straight into using SQL-DMO for something practical. Designing the add-in Enterprise Manager allows you to configure security settings for the objects in a database using the dialog shown in Figure 1. As you may be able to tell from this dialog, there are actually three possible settings for permissions: granted, denied, or not set. Security permissions in SQL Server are cumulative. If you grant permissions for some action to Figure 1. Permissions dialog in Enterprise Manager. one role or group but don t set the rights for another group, any user who is a member of both groups will be granted the right to perform that action. However, if you explicitly deny access to a particular command, any users who are members of this group will be denied the right to perform that function regardless of their rights in other groups (unless they re the database owner or belong to the sysadmins server role). Granted rights are represented in the dialog as check marks and denies as Xs. Permissions that haven t been explicitly set are shown as a blank check box, and permissions that don t apply to a particular object are shown as not having a check box. This is the dialog I wanted most to mimic. In order to get started, I needed two lists a list of objects in the database, and a list of users and roles in the database. SQL-DMO provides simple access to this information. Along with this information, I needed to determine the permissions applicable to an object and the current permissions assigned to each object for each user and role. You can see the final code for doing this in FillTables in frmpermissions in the add-in database. The SQL Server object exposes a Databases collection that provides access to the databases on the server. It takes a single argument the database name or collection index number. With a Database object in hand, getting a list of available objects is simply a matter of calling the ListObjects method of the database. This method returns a SQLObjectList collection that s an enumerable collection of DBObject objects (the DBObject class is a generic interface for all SQL Server database objects). The properties of the DBObject object are shown in Table 1. SQL-DMO Object Versions If you re using SQL-DMO for SQL Server 2000, you may notice that there are often two object types for many objects in the object model. For example, the SQLServer object comes in two flavors: SQLDMO.SQLServer and SQLDMO.SQLServer2. Microsoft did this in order to provide backwards compatibility with SQL Server 7. All of the 2 objects are designed to be used with SQL 2000 and expose methods, properties, or events not available in the earlier versions of SQL Server. Most of the code in the sample database uses the version 7-compatible objects. However, in a few cases I ve had to use the 2000-compatible objects in order to access collections that expose new objects like the UserDefinedFunctions collection that s new to The add-in assumes SQL Server 2000 is the version you ll use at all times. If you want to use it with SQL Server 7, you ll need to remove the references to the 2 objects and the code that references user-defined functions. Smart Access December

3 I created a table called tblobjects to hold information on the objects for which I wanted to set permissions. All I had to do was loop through the SQLObjectList and add those items that weren t system objects (obj.systemobject = False) or where the Type property told me that they were Default, Rule, or User-defined Datatypes (security doesn t apply to these objects). In order to easily be able to find the records I had added, I stored the ID property in an ObjectID field that s used as the primary key for the table. In order to determine the applicable permissions for each object, I simply had to use some prior knowledge of security on SQL Server objects. I wrote a function in basmain called ObjectTypePermissions. This function returns a SQLDMO.SQLDMO_PRIVILEGE_TYPE enumeration constant. If you look at the code, you ll see that the only odd case comes up when the object is a userdefined function. In this case, the rights are dependent on the type of function: scalar, in-line, or table. Scalar functions only support Execute rights, in-line ones support Select, Insert, Update, Delete, and DRI, and table functions support only Select and DRI. Now that I had a list of objects, I needed to use the Users collection of the Database object to access each user and the Roles collection to access each role. Users and roles are exposed in a Database object through different collections, the Users and the DatabaseRoles collections (respectively). Since the code that I needed to run to save the information for each object was virtually identical, I created a method called AddUserWithRights. This procedure takes the recordset to which I wanted to add the user or role, and a generic object for the User or DatabaseRole object. All I had to do to add the users and roles in the main code was loop through each collection and call the method I d created, as in the following code: For Each usr In db.users AddUserWithRights rstuser, usr Next For Each dbr In db.databaseroles If dbr.isfixedrole = False Then AddUserWithRights rstuser, dbr End If Next In this code, you may notice that I added a check for the roles against a property called IsFixedRole. This property tells you whether the role belongs to one of the standard SQL Server database roles. If this is the case, you cannot define rights for that role. The Users collection doesn t share this restriction, since it doesn t return any of the system users for which you cannot define permissions. Take a good look at the code in AddUsersWithRights this is where existing permissions are examined and stored. As I add each user or role to tbluserrole, I also check their permissions in the database. This is done by calling the ListObjectPermissions method of the User or DatabaseRole object. This method returns another SQLObjectList collection that contains Permission objects for the database. Each Permission object refers to a single explicitly set permission for the user. In other words, if a user has Select, Insert, and Update permissions granted (or denied), three Permission objects will be returned to specify this information. If the user doesn t have any explicit rights for an object, there won t be any corresponding members in this collection. Each Permission object has properties to determine what object the permission applies to and what the actual right is that s being examined. You can tell whether a right is granted or denied by checking the Granted property of this object. If the value of this property is True, the user has been granted permission, if it s False, Table 1. DBObject properties and methods. Property/Method Application CreateDate ID Name Owner Parent Properties SystemObject Type TypeName TypeOf UserData EnumDependencies ListPermissions ListUserPermissions Remove Script Description A reference to the current SQL-DMO Application object. The date the object was created. A system-defined object identifier assigned by SQL Server. This ID is unique and constant within the database. The ItemByID method can be used on a Database object to access any object by the value of this property. The name of the object in SQL Server. The name of the owner of this object. This can be used to properly qualify the object. A reference to the parent object that owns this object in this case, the Database object. A collection of properties for the object. A Boolean value specifying whether or not this is a system object. A long value of type SQLDMO_OBJECT_TYPE that can be inspected to determine what the object is (table, view, and so forth). A string name of the object type ( Table, View, UserDefinedFunction, and so on). See Type. A pointer to user-defined data associated with the object. A method to enumerate the dependencies of the object. A method that returns a SQLObjectList that exposes all defined security permissions for this object. Same as ListPermissions but allows you to limit to a particular user or role. Deletes the object from the database. Method to generate Transact-SQL script to create and/or drop the database object. 10 Smart Access December

4 the permission has been denied. Once the tables had been successfully populated, I could present the user with an interface for setting permissions. This interface is shown in Figure 2. As you can see, I ve chosen to represent set permissions as a checked check box, denied as a blank check box, and unset (or inapplicable) permissions as a null check box. Since Access can t store Null values in Boolean fields, I ve used a Long value to hold this data. The form looks and feels much like the permissions dialog in Enterprise Manager. You can filter using the various options on the form and switch between setting rights by user and by object. Once the user has configured the necessary permissions, all that s left is to apply the permissions to each object. The permissions subform automatically adds a flag to each record in tbluserobjectpermissions that specifies that the data has changed. This allows me to only apply rights where appropriate. When applying permissions, you don t need to set up individual permission objects, as they re returned by the ListObjectPermissions method. Instead, you can use one of three methods of the object in question to apply cumulative changes in one call: Revoke: This method clears explicitly set permissions for an object. Grant: This method grants permissions to perform Figure 2. frmpermissions. actions on an object. Deny: This method denies permissions to perform actions on an object. Each of these methods takes an enumerated type SQLDMO_PRIVILEGE_TYPE. To assign multiple permissions on an object, just OR values together (for instance, SQLDMOPriv_Select Or SQLDMOPriv_Insert will set Select and Insert permissions). Before I called Continues on page 19 Smart Access December

5 Using SQL-DMO... Continued from page 11 these methods, I used one other function NewRights. Remember that earlier I calculated and stored the applicable rights for each object. When applying the new rights, I used this information to mask out any erroneous values by ANDing each permission with the rights that apply to the object. If you try to assign invalid permissions for a particular object to any of these methods (like Select to a StoredProcedure), SQL-DMO will raise an error. Adding this check at the end just gave me an extra safety precaution so that the user wouldn t run into any problems. SQLDMO.ZIP at Russell Sinclair is an MSCD and is the owner of Synthesystems, a technology consulting firm that specializes in Visual Basic, SQL Server, and Microsoft Access development. He s the author of From Access to SQL Server, an Access developer s guide to migrating to SQL Server; a senior programmer with Questica, Inc., a company that specializes in software for custom-design manufacturers; and a Smart Access Contributing Editor. Where do we go from here? I have purposely left out a few features from this add-in (I just can t keep all the fun to myself). One of the security features that the SQL Server permissions dialog has is that it allows you to set Column-level permissions on tables and views. I haven t added this, so you might want to add it yourself. This add-in also doesn t provide any tools for adding users or roles to the database. Access 2000 already includes a tool to do this, but Access XP does not. You might want to make this a weekend project if you want the entire security configuration system available to you. SQL-DMO is extremely powerful. Every time I think that I ve hit upon an administrative feature that it doesn t implement, I quickly find it in the object model. If you re planning on deploying any ADP projects, you need to look into using this library. Providing an administrative interface to SQL Server is extremely important when control of your application passes out of your hands and into those of one of your users or another administrator. Smart Access December

6 Downloads December 2002 Source Code SQLDMO.ZIP This month s download from Russell Sinclair is an Access add-in for managing security in Access Data Projects. One of the major limitations to using Access Data Projects is the absence of the Microsoft administration tools The Source Code portion of the Smart Access Web site is available to paid subscribers only. Log in for access to all current and archive content and source code. For access to this issue only, go to click on Source Code, select the file(s) you want from this issue, and enter the User name and Password at right when prompted. 20 Smart Access December