|
|
Now that we've discussed why you want to use RBS, let's get on to how you're going to use it. In this case study, we'll build the security system in two basic stages:
Database tables: We'll build the tables needed to support the users and the required roles and permissions.
Stored procedures: We'll build the stored procedures required to allow you to create, alter and query these users, roles and permissions.
However, before you get started with the actual implementation of your database, we need to discuss some of the basic assumptions that underpin this implementation as well as some essential background information. In this case study, you're going to store and use bitmasked values to determine how a particular permission is mapped to a role. Therefore, we'll discuss some of the technology and math you're going to use for bitmasked access modes, as well as the naming convention you'll use for all of your stored procedures.
Before talking about a bitmasked access mode, we need to define what a bitmask actually is. As you know, the computer stores numbers in binary, which are all just long runs of zeros and ones. A bitmask uses the run of zeros and ones as the meaningful characteristic of that number rather than its decimal value.
For example, let's say you have the following value, in binary:
001100
In decimal, that value is 12. The value 12 has no meaning to you in terms of a bitmask. What you're actually looking at is a series of Boolean values. Each of the places in the binary number is actually going to be used as a Boolean value, or a flag. Rather than reading it in binary, you can look at the previous number as follows:
False False True True False False
So, instead of being able to store the single numeric value 12 in an integer-type data column, what you're actually storing is a large number of Boolean flags, or bits.
You might be thinking: Why would you use an Integer field to store a collection of bit flags when your database server allows you to create single columns that contain small fields that can be used as Booleans? After all, eight columns of the type Bit are going to take up just as much space as a single column of the type Byte, and each can store eight Boolean flags. So, why would you go to all the trouble of using a complex number that you have to perform bitwise operations on to figure out the Boolean values? Two words: extensibility and flexibility.
Let's say that for a sample Web site, you want users to have the following permission flags:
Create
Retrieve
Update
Delete
You're confident that the users are never going to need more permission assignments than this because this list covers the four basic types of operations you can perform on data. However, what happens if, six months after you build the application, you have to modify this list of flags so that there's a distinction between single items and batch items? In this system, you'd have to add four new columns to the database (Create Batch, Retrieve Batch, Update Batch, and Delete Batch), as well as add all of the extra stored procedure code to handle it. The programmers would probably have a fairly difficult task upgrading all of their code to work with the new data structure.
However, if you have a single column called Mode (or something similar) that was an integer, then in your database, if you have a 4-byte integer (32 bits), you actually have room to store up to 32 different permission flags (one for each bit) without having to worry about changing the data structure. Other database servers might have different size numeric value types available. You can create a column that will hold as many bits as you need flags for your security system. In addition, it's easier for programmers to pass around a single integer than it is to pass around a collection of Boolean values.
For the RBS system you're building in this case study, which could easily be the security system for an intranet or e-commerce Web site, you'll store permission grants on roles with a mode. Table 15-1 describes the bitmask values with which you're going to start.
|
Mode |
Bitmask Value |
Description |
|---|---|---|
|
Create |
1 (20) |
This permission mode allows the grantee to create a new item. What kind of item is determined by the permission granted—for example, a new user, new product, and so on. |
|
Transmit |
2 (21) |
This permission mode allows the grantee to create copies of one or more items in a portable transfer format, such as Extensible Markup Language (XML). |
|
Read |
4 (22) |
This permission mode allows the grantee to examine an item. Typically this means that the grantee is allowed to view lists of the item as well as individual items. |
|
Update |
8 (23) |
This permission mode allows the grantee to modify data belonging to a previously existing item. |
|
Delete |
16 (24) |
This permission mode allows the grantee to modify data belonging to a previously existing item. |
As you can see, you're only using five out of a potential 32 values. This gives you plenty of room to expand if you need to later. If you remember a little bit about binary math, a role that has Create, Transmit, and Delete permissions is going to have a mode value of 19 (simply add the numeric value assigned to Create(1), Transmit(2), and Delete(16) for the total). Note that there's no way of summing any of the other permission values to come up with a value of 19, so the combination of access modes is guaranteed to be unique.
A non-uniform naming convention will come back to haunt you. How many of you have created a suite of procedures for a particular application and later had someone else create more procedures for another application, which shared the same database, using a different naming convention? The result is confusion. For this case study, all stored procedures are prefixed with RBS_ (because this is a case study on RBS). Immediately following the RBS_ prefix is a description of the type of stored procedure, such as Select (multiple retrieve), Load (single retrieve), Update, Create, and Delete.
For example, a stored procedure to create a user might be called RBS_CreateUser, and a procedure to retrieve a list of users might be called RBS_SelectUsers.
Oracle has the concept of packages, which allow you to create logical groupings for your stored procedures and functions. So, in Oracle you could create a package called RBS and not need the prefix on the stored procedure names. You would refer to the stored procedures in such a package as RBS.CreateUser or RBS.SelectUsers. Other database servers have their own ways of distinguishing stored procedures for different applications.
|
|