6. Security and Object Access
This chapter discusses security and access at the object level.
6.1 GemStone Security
GemStone provides for blocking access to certain objects as well as sharing them. Applications can take advantage of several security mechanisms to prevent unauthorized access to, or modification of, sensitive code and data. These mechanisms are listed below, and you can choose to use any or all of them.
GemStone provides security at several levels:
- Login authorization keeps unauthorized users from gaining access to the repository;
- Privileges limit ability to execute special methods affecting the basic functioning of the system; and
- Object level security allows specific groups of users access to individual objects in the repository.
Complete details on GemStone security mechanisms are found in the System Administration Guide for your GemStone server product and version. A brief overview is included here.
Login Authorization
GemStone’s first line of protection is to control login authorization. When someone tries to log in to GemStone, GemStone requires a user name and password. If the user name and password match the user name and password of someone authorized to use the system, GemStone allows interaction to proceed; if not, the connection is severed.
The GemStone system administrator controls login authorization by establishing user names and passwords when he or she creates UserProfiles.
The UserProfile
Each instance of UserProfile is created by the system administrator. The UserProfile contains information about you as an individual user, such the UserId and password, your SymbolList, any groups you belong to, and your privileges. This information is used to provide system and object level security, including object visibility.
Controlling Visibility of Objects with SymbolLists
One way to control access is to hide certain objects from users. Each GemStone user has a SymbolList, containing a collection of SymbolDictionaries to which they have been given access. Objects, such as Classes, that are not found in a search of the user’s SymbolLists are not accessible. Because it is difficult for users to refer to objects that are not defined somewhere in their symbol lists, simply omitting off-limits objects from a user’s symbol list avoids the accidental or inadvertent use of these objects, and provides a small measure of security. It is possible, however, for users to find ways to circumvent this, since it’s difficult to ensure that all indirect paths to an object are eliminated.
NOTE
For performance reasons, GbsSession uses transient copies of your symbol lists. If you change this transient copy programmatically, the changes are not immediately reflected in the permanent GemStone object. Also, changes to the permanent GemStone symbol list are not reflected in the GbsSession’s transient symbol list until a transaction boundary. If you must be absolutely certain that the two copies are synchronized, log out and log back in again.
System Privileges
Users require CodeModification privilege before they can make changes to GemStone server classes and methods, and a number of other GemStone Smalltalk methods are also limited to those who have explicitly been given the necessary privileges. The privilege mechanism is entirely independent of the authorization mechanism. This mechanism allows the system administrator to control who can send certain powerful messages, such as those that halt the system or change passwords.
Specific privileges and the privileged messages are described in the image, and their use is discussed in the System Administration Guidee.
Protecting Methods
Another choice is to implement procedural protection. If your program accesses its objects only through methods, you can control the use of those objects by including user identity checks in the accessing methods.
Object-level Security
Object Security Policies
Instances of GemStone’s GSObjectSecurityPolicy Class provide read and write authorization control to individual objects. When someone tries to read or write an object that is governed by an object security policy for which he or she lacks the proper authorization, GemStone raises an authorization error and does not permit the requested operation.
Objects may be associated with an object security policy or not. If not, no object authorization is done and any user can read and write the objects.
NOTE
In the 32-bit GemStone/S server product, and in GemStone/S 64 Bit 2.x, object security policies are known as Segments. In 32-bit GemStone/S, nil Segments are disallowed.
All objects associated with a particular object security policy have exactly the same protection; that is, if you can read or write one object with that security policy, you can read or write them all. Each security policy is owned by a specific single user, and may have authorizations for owner, groups, or world for read-only, read-write, or no access.
Groups provide a way to allow a number of GemStone users to share the same level of access to set of objects in the repository.
Object security policies are not meant to organize objects for retrieval; GemStone uses Symbol Lists for that. Moreover, security policies don’t have any relationship to the physical location of objects on disk; they merely provide access security.
For a complete discussion of object level security, symbol resolution, and object sharing, see the relevant chapters of the Programming Guide.
6.2 X509-Secured GemStone
Starting with GemStone/S 64 Bit v3.5, the GemStone server supports X509-Secured GemStone, in which all interprocess communication requires mutual X.509-certificate based authentication.
This mode provides many other security features. See the GemStone/S 64 Bit X509-Secured GemStone System Administration Guide for more details.
X509-Secured Gemstone requires a different set of session parameters for login. GemBuilder provides parallel support for X509 and regular session parameter logins.