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.
• The SymbolList used for resolving symbols when compiling, including SymbolDictionaries such as Globals and UserGlobals. Chapter 3, “Resolving Names and Sharing Objects”, discuses these topics.
• The groups to which you belong
• The privileges you may have.
• A default GsObjectSecurityPolicy to assign your session at login, or nil.

See the System Administration Guide for instructions on creating UserProfiles, defining groups, and assigning users to groups.

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; references to Segment now mean GsObjectSecurityPolicy).

All objects assigned the same 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.

There are several ways that access to objects is controlled by the security policy:

• Each policy is owned by a single user, and all objects assigned the same security policy have the same owner. The owner has write and read access to all objects associated with the security policy.
• A security policy has a setting for world; this allows every authorized GemStone user to have read, write, or no access to all the objects associated with a security policy
• Groups of users can be defined, and these groups can be configured to have read, write, or no access to all the objects associated with a security policy.

In addition, 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’s group membership and security policy authorization control access to objects, as shown by Figure 9.1.

Figure 9.1 User Access to Application ObjectSecurityPolicyA

---

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.

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 ObjectSecurityPolicyC, which enforces more restricted access than ObjectSecurityPolicyA.

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.

anObjectSecurityPolicy group: 'Managers' authorization: #read

anObjectSecurityPolicy worldAuthorization: #none

GsObjectSecurityPolicy names

Most of the system security policies have Symbolic references in Globals and can the name can be used in code. SecurityPolicies may have names (which are stored in a dynamic instance variable); most system security policies have names set. When defining a new object security policy, you may send name: to make it more easily identifiable. This does not itself create a global reference.

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

DataCuratorObjectSecurityPolicy(#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

	self assignToObjectSecurityPolicy: aPolicy.

	self 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.5. 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.

World Access

To begin analyzing your access requirements, check whether the objects have any Ns. For objects that do, world authorization must be set to none.

If you have people who need read access to nonsensitive information, give world read authorization to those objects. In this example, world can have read access to anEmployee, name, position, dept., and manager. The objects can still be protected from casual browsing by storing them in a dictionary that does not appear in everyone’s symbol list. This does not absolutely prevent someone from finding an object, but it makes it difficult. For more information, see Chapter 3, “Resolving Names and Sharing Objects”.

Owner

By default, the owner has write access to the objects protected by a security policy. To choose an owner, look for a user who needs to modify everything. In terms of the basic user categories described earlier, the owner could be either an administrator or an updator. This depends on the type of objects that will be assigned to the security policy.

In Table 9.1 the system administrator is the user who needs write access. So the system administrator is made the owner, with full control of all the objects. The DataCurator and SystemUser logins are available to the system administrator. The DataCurator is not automatically authorized to read and write all objects, however. Like any other user account, it must be explicitly authorized to access objects in security policies it does not own. Although the SystemUser can read and write all objects, it should not be used for these purposes.

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.7 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.7). 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.