9. Object Security and Authorization

The UserProfile

Each instance of UserProfile is created by the system administrator. The UserProfile is stored with a set of all other UserProfiles in a set called AllUsers. The UserProfile contains:

• Your UserID and Password.
• A SymbolList (the list of symbols, or objects, that the user has access to— UserGlobals, Globals, and Published) for resolving symbols when compiling. Chapter 3, “Resolving Names and Sharing Objects”, discuses these topics.
• The groups to which you belong and any special system privileges you may have.
• A default GsObjectSecurityPolicy to assign your session at login, or nil.

See the System Administration Guide for instructions about creating UserProfiles.

GsObjectSecurityPolicy

Each object's header includes a 16-bit unsigned security policy Id that specifies the GsObjectSecurityPolicy to which the object has been assigned. In previous releases, object security policies were known as Segments. In GemStone/S 64 Bit 3.0, Segment has been renamed to GsObjectSecurityPolicy, to more clearly represents its function. All references to Segment in previous releases now pertain to GsObjectSecurityPolicy.

All objects assigned to an security policy have exactly the same protection. That is, if you can read or write one object assigned to a certain policy, you can read or write them all. Each policy is owned by a single user, and all objects assigned to the same security policy have the same owner. Groups of users can have read, write, or no access to an security policy. Likewise, any authorized GemStone user can have read, write, or no access to a policy.

An object may also have no security policy, in which case its security policy Id is zero. This means that there are no restrictions on access to this object; any logged-in user can read and write this object.

Whenever an application tries to access an object, GemStone compares the object’s authorization attributes in the security policy associated with the object with those of the user whose application is attempting access. If the user is appropriately authorized, the operation proceeds. If not, GemStone returns an error notification.

The user name, group membership, and security policy authorization control access to objects, as shown by Figure 9.1:

Figure 9.1 User Access to Application ObjectSecurityPolicy1

Example 9.1

| aPolicy myPolicy |

myPolicy := System myUserProfile 	

	defaultObjectSecurityPolicy.

aPolicy := GsObjectSecurityPolicy new.

System commitTransaction.

"change my current security policy to aPolicy"

System currentObjectSecurityPolicy: aPolicy

Only committed instances of GsObjectSecurityPolicy can be used.

If you commit after changing the security policy, the new GsObjectSecurityPolicy remains your current security policy until you change the security policy again or log out. If you abort after changing your current security policy, your current security policy is reset from your UserProfile’s default security policy.

Unnamed GsObjectSecurityPolicies are often stored in a UserProfile, but named GsObjectSecurityPolicies are stored in symbol dictionaries like other named objects. Private security policies are typically kept in a user’s UserGlobals dictionary; security policies for groups of users are typically kept in a shared dictionary.

You can also put security policies in application dictionaries that appear only in the symbol lists of that application’s users.

Example 9.2

| myPolicy |

"get default security policy"

myPolicy := System myUserProfile defaultObjectSecurityPolicy.

"compare with current"

myPolicy = System currentObjectSecurityPolicy

true

Compound Objects

Usually, the objects you are working with are compound, and each part is an object in its own right, with its own security policy assignment. For example, look at anEmployee in Figure 9.2. The contents of its instance variables (name, salary, and department) are separate objects that can be assigned to different security policies. Salary is assigned to ObjectSecurityPolicy2, which enforces more restricted access than ObjectSecurityPolicy1.

Figure 9.2 Multiple Security Policy Assignments for a Compound Object

Collections

When you assign collections of objects to security policies, you must distinguish the container from the items it contains. Each of the items must also be assigned to the proper policy. Distinguishing between a collection and the objects it contains allows you to create collections most elements of which are publicly accessible, while some elements are sensitive.

How GemStone Responds to Unauthorized Access

GemStone immediately detects an attempt to read or write without authorization and responds by stopping the current method and issuing an error. When you successfully commit your transaction, GemStone verifies that you are still authorized to write in your current security policy. If you are no longer authorized to do so, GemStone issues an error, and your default security policy once again becomes your current security policy. If you are no longer authorized to write in your default security policy, GemStone terminates your session, and you are unable to log back in to GemStone. If this happens, see your system administrator for assistance.

Owner, Group, and World Authorization

A GsObjectSecurityPolicy controls what access a user has to associated objects. Access can be separately assigned for:

• a security policy’s owner
• groups of users (by name)
• the world of all GemStone users

Whenever a program tries to read or write an object, GemStone compares the object’s authorization attributes with those of the user who is attempting to do the reading or writing. If the user has authorization to perform the operation, it proceeds. If not, GemStone returns an error notification.

These categories overlap. The owner of a security policy is also in the world of all GemStone users, and may also be in one or more groups that have other access authorization. When determining a user's authorization, the most permissive or generous authorization will be allowed and other, more restrictive authorizations, will be ignored. Thus, if world authorization is #read, but the user is a member of a group with #write authorization, then the world authorization will be ignored.

Group Authorization

Groups are an efficient way to ensure that a number of GemStone users all will share the same level of access to objects in the repository, and all will be able to manipulate certain objects in the same ways.

Groups are typically organized as categories of users who have common interests or needs. In Figure 9.3, for example, a group named Managers was set up to allow a few users to read the objects in anObjectSecurityPolicy, while GemStone users in general aren’t allowed any access.

Figure 9.3 User Access to a Security Policy’s Objects

 

 

The global collection AllGroups, a collection of group names, defines all groups in the system. Membership in a group is granted by having adding the group name to the user’s UserProfile groups.

The message GsObjectSecurityPolicy>>authorizationForGroup: groupNameString returns the rights for users in the group groupNameString.

The message GsObjectSecurityPolicy>>groupsWithAuthorization: anAuthSymbol returns the names of groups that have a particular level of access (#read, #write, or #none) for the receiver security policy.

To set group access, use the message GsObjectSecurityPolicy>>group: groupNameString authorization: anAuthSymbol. For example, to set the group authorization as shown in Example 9.3, use the following:

anObjectSecurityPolicy group: 'Managers' authorization: #read

anObjectSecurityPolicy worldAuthorization: #none

Changing the Security Policy for an Object

If you have the authorization, you can change the accessibility of an individual object by assigning a different security policy to it.

The message Object >> objectSecurityPolicy returns the security policy that protects that receiver, or nil if the receiver does not have an associated security policy:

UserGlobals objectSecurityPolicy

%

anObjectSecurityPolicy, Number 2 in Repository SystemRepository,

Owner DataCurator write, Group DataCuratorGroup write, World read

Employee objectSecurityPolicy: aPolicy.

Array subclass: 'Menagerie'

	instVarNames: #() 

	classVars: #()

	classInstVars: #()

	poolDictionaries: {}

	inDictionary: UserGlobals

%

method: Menagerie

objectSecurityPolicy: aPolicy

"Assign the receiver and each component to the given objectSecurityPolicy."

self assignToObjectSecurityPolicy: aPolicy.

1 to self size do:

	[:eachAnimal | eachAnimal

		objectSecurityPolicy: aPolicy. ]

%

"Return the userId of the owner of the default security policy for

the current Session."

| aUserProf myDefaultPolicy |

"get default security policy"

myDefaultPolicy := System myUserProfile

	defaultObjectSecurityPolicy.

myDefaultPolicy notNil ifTrue:

	["return its owner’s UserProfile"

	aUserProf := myDefaultPolicy owner.

	"request the userId"

	aUserProf userId]

%

user1

System myUserProfile defaultObjectSecurityPolicy owner: aUserProfile

Revoking Your Own Authorization: a Side Effect

You may occasionally want to create objects and then take away authorization for modifying them.

CAUTION
Do not remove your write authorization for your default security policy or your current security policy. If you lose write authorization for your default security policy, you will not be able to log in again.

Finding Out Which Objects Are Protected by a Security Policy

It may be useful for you to be able to find all the objects that are protected by a particular security policy. An expression of the form:

SystemRepository listObjectsInObjectSecurityPolicies: anArray

takes as its argument an array of security policy IDs, and returns an array of arrays. Each inner array contains all objects whose security policy ID is equal to the corresponding security policy ID element in the argument anArray. Instances to which you lack read authorization are omitted without notification.

Note that this method aborts the current transaction and scans the object header of each object in the repository.

If the result set is very large, there is a risk of out of memory errors. To avoid the need to have the entire result set in memory, the following methods are provided:

Repository >> listObjectsInObjectSecurityPolicyToHiddenSet: anObjectSecurityPolicyId

This method puts the set of all objects in the specified security policy in the ListInstancesResult hidden set. (a hidden set is an internal memory structure that, while not an object, is treated as one).

To enumerate the hidden set, you can use this method:

System >> hiddenSetEnumerate: hiddenSetId limit: maxElements

using a hiddenSetId of 1, which is the number of the “ListInstancesResult” hidden set in GemStone/S 64 Bit v3.2. This hidden set number is subject to change in new releases; to determine which hidden sets are in a particular release, use the GemStone Smalltalk method System Class >> HiddenSetSpecifiers. For more on hidden sets, see Other Optimization Hints.

You can also list objects that are protected by a particular security policies to an external binary file, which can later be read into a hidden set. To do this, use the method:

Repository >> listObjectsInObjectSecurityPolicies: anArray toDirectory: aString

This method scans the repository for the instances protected by the security policies in anArray and writes the results to binary bitmap files in the directory specified by aString. Binary bitmap files have an extension of .bm and may be loaded into hidden sets using class methods in System.

Bitmap files are named:

objectSecurityPolicy<ObjectSecurityPolicyId>-objects.bm 

where ObjectSecurityPolicyId is the security policy ID.

The result is an Array of pairs. For each element of the argument anArray, the result array contains ObjectSecurityPolicyId, numberOfInstances. The numberOfInstances is the total number written to the output bitmap file.

Protecting the Application Classes

All the application users need read access to the application classes and methods, so they can execute the methods. To prevent accidental damage to them, however, you probably want to limit write access. The CodeModification privilege is required to create or modify classes and methods. You can further limit write access using security policies. You may even want to change the owner’s authorization to read, until changes are required.

Like other objects, classes and their methods are assigned to security policies on an object-by-object basis. You may keep separate subsections of your application in different security policies, with different write authorizations, if you want.

CodeModification privilege

All application developers will need to have CodeModification privilege. This is in addition to the ability to read and write the appropriate security policies. Without CodeModification privilege, you cannot compile methods or classes, add new methods, add a Class to a SymbolDictionary, or perform other operations required for application development.

Application users, on the other hand, should not have CodeModification privilege, since they will not be modifying methods or classes. This allows you to protect the application code for inadvertent (or intentional) damage or modification, even if you do not want to implement object level security.

Planning Authorization for Data Objects

Authorization for data objects means protecting the instances of the application’s classes, which will be created by end users to store their data. You can begin the planning process by creating a matrix of users and their required access to objects. Table 9.1 shows part of such a matrix, which maps out access to instances of the class Employee and some of its instance variables.

Security is easier to implement if it is built into the application design at the beginning, not added later. In the following sections, planning for the third stage, end user access, comes first. Following the planning discussion comes the implementation instructions, which explain how to set up security policies for the developers, extend the access to the testers, and finally move the application into production.

Remember that in effect you have four options, shown on the matrix as:

W — need to write (also allows reading)

R — need to read, must not write

N — must not read or write

blank — don’t need access, but it won’t hurt

Planning Groups

The rest of the access requirements must be satisfied by setting up groups. The thing to remember about groups is that they do not reflect the organization chart; they reflect differences in access requirements. Because the number of possible authorization combinations is limited, the number of groups required is also limited.

First look at the existing access to anEmployee, name, position, dept., and manager, as shown in Table 9.2. By making the system administrator the owner with write authorization and assigning read authorization to world, you have already satisfied the needs of five departments.

You still need to provide authorization for the Human Resources and Employee Records departments. In every case, they need the same access (see Table 9.1) so you only have to create one group for the two departments. This group, named Personnel, requires write authorization for the objects in Table 9.2.

Now look at the existing access to the rest of the objects. These objects store more sensitive information, so access requirements of different users are more varied. Assigning write authorization to owner and none to world has completely satisfied the needs of three departments, as shown in Table 9.3.

Two more departments, Human Resources and Employee Records, are already set up to access as the Personnel group. As shown in Table 9.4, this group needs write authorization to dateHired, vacationDays, and sickDays, which they must be able to read and modify. They need read authorization to salary, salesQuarter, and salesYear, which they must read but cannot modify.

Now the Payroll and Sales departments still require access to the objects, as shown in Table 9.3. Because these departments’ needs don’t match anyone else’s, they must each have a separate group.

In all, this example only requires three groups: Personnel, Payroll, and Sales, even though it involves seven departments.

Planning Security Policies

When you have been through this exercise with all your application’s prospective objects and users, you are ready to plan the security policies. For easiest maintenance, use the smallest number of security policies that your required combinations of owner, group, and world authorizations allow. You don’t need different security policies with duplicate functionality to separate particular objects, like the application classes and data objects. Remember that symbol lists, not security policies, are used to organize objects for listing and retrieval.

In this example you need six security policies, as shown in Figure 9.8. Notice that each one has different authorization.

Setting Up Security Policies for Joint Development

To make joint development possible, you need to set up authorization and references so that all the developers have access to the classes and methods that are being created. Create a new symbol dictionary for the application and put it in everyone’s symbol list; make sure it includes references to any shared security policies. If only developers are using the repository, you can give world access to shared objects, but if other people are using the repository, you must set up a group for developers.

You can organize security policy assignments in various ways:

• Full access to all personal security policies. Give all the developers their own default security policies to work in. Give everyone in the team write access to all the security policies. Because the objects you create are typically assigned to your default security policy, this method may be the simplest way to organize shared work.
• Read access to all personal security policies. Set up the same as above, except give everyone read access to the security policies. If each developer is doing a separate module, read access may be enough. Then everyone can use other people’s classes, but not change them. This has the advantage of enforcing the line between application and data.
• Full access to a shared security policy. Give all developers the same default security policy, writable by everyone. This is an easy, informal way to share objects.
• Full access to a shared security policy plus private security policies. Developers work in their own default security policies and reassign their objects to the shared security policy when they are finished. This lets you share a collection, for example, but keep the existing elements private, so that other developers could add elements but not modify the elements you have already created. To share a collection this way, assign the collection object itself to the accessible security policy. The collection has references to many other objects, which can be associated with other security policies. Everyone has the references, but they get errors if they try to access objects with non-readable security policies. You might also choose to share an application symbol dictionary, so that other developers can put objects in it, without making the objects themselves public.

Figure 9.8 Security Policies Required for User Access to Application Objects

Making the Application Accessible for Testing

Testers need to be able to alternate between two distinct levels of access:

• Full access. As members of the development team, they need read access to all the classes and methods in the application, including the private methods. Testers also need write access to their test data.
• User-level access. They need a way to duplicate the user environment, or more likely several environments created for different user groups.

This can be done by setting up a tester group and one or more sample user groups during the development phase. For testing the user environment, the application must already be set up for multi-user production use, as explained in the following section.

Moving the Application into a Production Environment

When you have created the application, it is time to set it up for a multi-user environment. A GemStone application is developed in the repository, so all you have to do to install an application is to give other users access to it. This means implementing the rest of your application design, in roughly the reverse order of the planning exercise. To give other users authorization to use the objects in the application:

1. Create the security policies.

2. Create the necessary user groups specified in up-front development, if they don’t exist.

3. Assign the required owner, world, and group authorizations to the security policies.

4. Assign testers to the user groups and complete multi-user testing.

5. Assign any end users that need group authorization to the user groups.

6. Assign the application’s objects to the security policies you created.

You also have to give users a reference to the application so they can find it. An application dictionary is usually created with references to the application objects, including its security policies. A reference to this dictionary usually must appear in the users’ symbol lists. For more information on the use of symbol dictionaries, see the discussion of symbol resolution and object sharing in Chapter 3, “Resolving Names and Sharing Objects”.

Assign a Specified Security Policy to the User Account

Set up users with the proper security policy by default. This is a simple way to assure that someone who creates objects in a single security policy doesn’t misplace them. To make it impossible to change security policies, rather than just unlikely, you also have to close write access for group and world to all the other security policies.

This solution would work for the Sales and Payroll groups in the example (Figure 9.8). They need read access to several security policies, but they only write in one.

The drawback of this solution is that the user can only use one security policy.

Develop the Application to Create the Data Objects

Your best choice is to create objects in the correct security policy, using the GsObjectSecurityPolicy>>setCurrentWhile: method. With this method, the application stores data objects in the proper security policies. This provides the most protection. Besides guaranteeing that the objects end up in the proper security policy, this prevents users from accidentally modifying objects they have created. It also prevents them from reading the data that other users enter, even when everyone is creating instances of the same classes.