8. User Accounts and Security

SystemUser

SystemUser is analogous to root in UNIX. SystemUser is not restricted by any privileges, belongs to all predefined groups, and is authorized to read and write all objects regardless of GsObjectSecurityPolicy protection. These privileges cannot be taken away, so SystemUser can always write to all objects. This account is used only to perform GemStone system upgrades, modify some system configuration settings, and other special-purpose operations that must be highly restricted.

SystemUser can only be configured to use GemStone authentication and cannot be disabled.

The SystemUser account is the owner of the SystemObjectSecurityPolicy, which contains the kernel classes.

WARNING
Logging in to GemStone as SystemUser is like logging in to your workstation as root: an accidental modification to a kernel object can cause a great deal of harm. Use the DataCurator account for system administration functions except those that require SystemUser privileges, such as a repository upgrade.

DataCurator

The DataCurator account is the account that is normally used for day-to-day administration tasks. Initially, DataCurator is granted all privileges and belongs to all predefined groups, but unlike SystemUser, does not have the ability to read and write all GsObjectSecurityPolicies.

DataCurator can be configured to use GemStone or SingleSignOn authentication, but not LDAP or UNIX, and cannot be disabled.

All GemStone UserProfiles are protected by the DataCuratorObjectSecurityPolicy.

GcUser

The GcUser account is a special account that logs in to the repository automatically to perform garbage collection tasks. The only reason to login as GcUser is to examine or update configuration parameters stored in GcUser’s UserGlobals, although this is done more conveniently by executing code.

GcUser can be configured to use GemStone or SingleSignOn authentication, but not LDAP or UNIX, and cannot be disabled.

SymbolUser

The SymbolUser account is a special account that is used to perform symbol creation tasks. Login as SymbolUser is disallowed. Directly accessing the AllSymbols collection, which is in the UserGlobals of the SymbolUser, is possible from another administrative session.

Nameless

The Nameless account is a special account for use only by other GemStone products. Login as Nameless is disallowed. Do not use this account or change it unless instructed to do so by GemStone Technical Support;

HostAgentUser

The HostAgentUser account is a special account for use only by X509-Secured GemStone processes. Do not use this account or change except as directed by GemStone Engineering.

User ID

Each UserProfile is created with a unique user Id String. User Ids may contain alphanumeric Characters with values up to code point 255, or _ (underscore, code point 95), - (hyphen, code point 45), . (dot, code point 46), or space (code point 32). Existing UserProfiles in upgraded repositories may contain additional characters.

UserId may only be changed by SystemUser or by a user with the privilege #ChangeUserId. The userIds of special system users cannot be changed.

Authentication Scheme

When a user wants to log in to the GemStone repository, their login must be authenticated: they must present a password that is matched against stored information for their UserId, to verify that they are authorized to log in. This authentication can be done entirely within GemStone, or GemStone can use UNIX, LDAP, or Kerberos to perform the authentication.

There is another authentication, X509, which requires a different login infrastructure; this is not described in detail here, see the GemStone/S 64 Bit X509-Secured GemStone System Administration Guide for more information. Users who are configured with other authentication schemes can both login using traditional login, and login using X509-secured GemStone. Users configured with X509 authentication are restricted to only logging in using X509-secured GemStone

Performing the authentication entirely within GemStone – Gemstone authentication – is the initial default for all users. Other authentication schemes can be configured for individual UserProfiles, though there are restrictions for system accounts. The repository may contain UserProfiles using a mix of authentication schemes.

After the authentication scheme is modified for a user and the change is committed, it will take effect the next time the user logs in. Existing logins are not affected.

In addition to authentication for the GemStone UserProfile, users may need to authenticate the UNIX username, before the NetLDI will start the Gem process for an RPC login. This depends on how the system is configured; see Chapter 4 for details on interprocess security and host authentication.

Changing authentication requires #OtherPassword privilege. Inquiring about authentication requires either #OtherPassword or #ReadOtherUserProfile.

Setting up GemStone and other authentication schemes is described in more detail starting here.

topaz 1> printit

(AllUsers userWithId: 'DataCurator') authenticationScheme.

%

GemStone

Password

Passwords for GemStone authentication must be:

• invariant Strings
• not empty
• be different than the User Id
• no longer than 1024 characters
• contain only Characters with codePoints under 256

When each UserProfile is created, the initial password is defined and the account starts off using GemStone authentication. If the UserProfile is modified to use another authentication scheme, the initial password is discarded. For GemStone authentication, the password supplied in the login parameters is verified against this password.

GemStone authentication provides a number of controls on passwords, which apply to changing passwords and constraints on choice of password.

Default Object Security Policy

A users’ defaultObjectSecurityPolicy determines the default read and write authorizations for objects created by the user. When you add a new user to the GemStone system, you can either allow the default security policy to be nil, use protocol that creates a new GsObjectSecurityPolicy, or specify an existing GsObjectSecurityPolicy for the user.

For more information on how security policies are used to control read and write authorization for objects in the repository, see the chapter in the Programming Guide that discusses security.

A defaultObjectSecurityPolicy of nil means that objects created by that user, by default, have world read and write access; that is, are not restricted from being read or written by all other users. Not requiring authorization checks has the benefit of improved performance, if your application does not require object level security.

When creating a user, you can use methods that specify that a new instance of GsObjectSecurityPolicy should be created and assigned as the default for the new user. Otherwise, you must use an already committed instance of GsObjectSecurityPolicy, either existing or newly created, or nil.

If the defaultObjectSecurityPolicy for a user is not nil, the user MUST have write authorization to this security policy; otherwise, this user will not be able to log in.

To modify your own defaultObjectSecurityPolicy, you must have the #DefaultObjectSecurityPolicy privilege. To modify the defaultObjectSecurityPolicy of another user, you must have this privilege, and write access to the security policy of that UserProfile.

Symbol Lists

As explained in the Programming Guide, the GemStone Smalltalk compiler follows a well-defined path in resolving objects named by source code symbols. First, the compiler considers the possibility that a variable name might be either local (a temporary variable or an argument) or defined by the class of the current method definition (an instance variable, a class variable, or a pool variable). If a variable is none of these, the compiler refers to an Array of SymbolDictionaries in the user’s UserProfile and current session state. That Array is called the user’s symbol list. The symbol list tells Smalltalk which of many possible GemStone SymbolDictionaries to search for an object named in a Smalltalk program.

For each user, a persistent instance of class SymbolList is stored in the repository and is referenced from the UserProfile associated with this user as the symbolList instance variable. In addition, a transient copy of that SymbolList is stored in the GsCurrentSession object for the logged-in session.

A session’s transient copy can be modified without affecting (or causing concurrency conflicts with) either the persistent symbol list or the transient copies controlling other sessions. Changes to your own UserProfile’s persistent symbol list also change the symbol resolution of your current session. However, changes to the persistent symbol list are likely to cause concurrency conflicts with other sessions logged in under the same userId.

For further information about symbol lists, refer to the Programming Guide.

New UserProfiles are created with the following SymbolDictionaries, in this order:

Although all users automatically share access to objects in Globals, sharing application objects between users requires that the objects be in a SymbolList that is visible to both users. There are three primary ways to do this:

• As a member of group Publishers, you can add the objects to the Published dictionary. This dictionary is already in each user’s symbol list, so whatever you add becomes visible to users the next time they obtain a fresh transaction snapshot view of the repository. You may do this by sending the message Published at: aKey put: aValue.
• You can define a special SymbolDictionary, and add that to the user’s SymbolList. The procedure is described under Adding a SymbolDictionary to Someone Else’s Symbol List.
• The application itself can add the objects to the individual user’s symbol list, either to the permanent symbol list in the UserProfile or to a transient symbol list for that session. For information about this approach, refer to the Programming Guide.

For more information, refer to the chapter on symbol resolution and object sharing in the Programming Guide.

Privileges

When you create a new UserProfile, you determine whether the new user may perform certain “privileged” system functions. For example, stopping another session, or the repository itself, requires a particular privilege to do so. Table 8.1 describes the types of functions that each privilege controls.

Note that privileges are more powerful than security policy authorization. Although the owner of a security policy can always use authorization protocol to restrict read or write access to objects in a policy, an administrator with appropriate privileges, such as DataCurator, can override that protection by sending privileged messages that let you change the authorization scheme.

Attempting to removing privileges from SystemUser has no effect, only SystemUser can remove privileges for other special users.

The inverse privileges, NoGsPerformOnServer and related

Some operations, like executing performOnServer:, are allowed by default for all users. Since access to operating system functionality and disk files is a security issue, this functionality can be disabled for specific users by assigning an inverse privilege.

For the privileges NoGsPerformOnServer, NoUserAction, NoGsFileOnServer, and NoGsFileOnClient, the user that has that privilege is disallowed from performing the associated operations.

Allowlist for performOnServer:

Accessing OS functions using performOnServer: (and the related GsHostProcess functionality) is very useful, and for some applications it may be necessary for users that should not have general OS command access, to be able to execute specific OS commands.

This can be set up via a per-user allowlist. To allow a user with the NoPerformOnServer privilege to execute a specific command, the full path (starting with / and ending with the command name) to the command is put on an allow list for that specific user. The full path must then be specified on the performOnServer: or GsHostProcess method argument; the paths and commands must match exactly for the execution to be permitted.

There are no checks or restrictions on arguments to the commands; only the commands themselves are examined and allowed (or not).

The following methods add one or more commands to the allowlist:

UserProfile >> addPerformOnServerCommand: fullPathToCommand

UserProfile >> addPerformOnServerCommands: arrayOfCommands

To report the existing allowlist:

UserProfile >> performOnServerCommands

To remove commands from the allowlist:

UserProfile >> removeAllPerformOnServerCommands

UserProfile >> removePerformOnServerCommand: aString 

UserProfile >> removePerformOnServerCommands: arrayOfString

The requirement to use full paths in the allowlist and in the argument to performOnServer: applies to operating system commands such as ls. While users without NoPerformOnServer can pass commands such as 'pwd' and 'ls' to performOnServer:, and rely on the path lookup, users with NoPerformOnServer must configure the allowlist to include the full path, such as '/bin/pwd' and '/bin/ls', and pass the same full path to performOnServer:.

For example, as DataCurator or another privileged user, update a non-privileged user ReadingUser by executing:

(AllUsers userWithId: 'ReadingUser') addPrivilege: 'NoPerformOnServer'; addPerformOnServerCommand: '/usr/bin/git'.

System commitTransaction.

Now, as ReadingUser, the following will succeed:

System performOnServer: '/usr/bin/git log'

But ReadingUser cannot perform other OS commands, such as ls or cp. Each individual executable to be allowed must be specifically entered in the allowlist.

Simple User Creation

At minimum to create a new UserProfile, you must supply the new user’s userId and password, each as a String. This creates the new user with no privileges, only the Subscribers group, and with a nil defaultObjectSecurityPolicy.

AllUsers addNewUserWithId: 'theUserId' 

	password: 'thePassword'.

Simple User Creation with GsObjectSecurityPolicy Creation

To create a new user and specify that a new instance of GsObjectSecurityPolicy should be created for the new user, use the following expression:

AllUsers addNewUserWithId: 'theUserId' 

	password: 'thePassword'

	createNewSecurityPolicy: true

User Creation With Privileges, Groups, and ObjectSecurityPolicy

Using the complete form allows you to assign privileges to the new user, add the user to one or more groups, and specify a default ObjectSecurityPolicy. The ObjectSecurityPolicy may be nil.

AllUsers addNewUserWithId: 'theUserId'

    password: 'thePassword'

    defaultObjectSecurityPolicy: anObjectSecurityPolicyOrNil

    privileges: anArrayOfPrivSyms

    inGroups: aCollectionOfGroupsOrGroupNames

For example:

topaz 1> printit

AllUsers addNewUserWithId: 'Mary'

	password: 'herPasswd'

	defaultObjectSecurityPolicy: nil

	privileges: #( UserPassword )

	inGroups: #( 'MarathonRunners' ).

System commitTransaction.

%

For additional user creation protocol, see the image. UserProfileSet instance methods and UserProfile class methods both create new UserProfiles and add the new user to AllUsers.

Remove User, with ObjectSecurityPolicies Going to the Current User

The following methods remove the user and reassign any GsObjectSecurityPolicies owned by the user to be removed to the UserProfile of the current user (the user executing this code, such as DataCurator).

AllUsers removeAndCleanup: aUserProfile.

AllUsers removeAndCleanupUserWithId: ‘aUserId’ ifAbsent: aBlock

Remove User, with ObjectSecurityPolicies going to another User

The following methods remove the user and reassign any GsObjectSecurityPolicies owned by that user to another specific UserProfile.

AllUsers removeAndCleanup: aUserProfile

	migrateSecurityPoliciesTo: anotherUserProfile.

AllUsers removeAndCleanupUserWithId: ‘aUserId’

migrateSecurityPoliciesToUserWithId: ‘anotherUserId’

ifAnyAbsent: aBlock

For example,

topaz 1> printit

AllUsers removeAndCleanup: (AllUsers userWithId: 'John')

	migrateSecurityPoliciesTo: (AllUsers userWithId: 'Ann')

System commitTransaction.

Adding a user to a group

UserProfileGroup >> addUser: aUserProfile
Add the given UserProfile to the receiver, and add the receiver to this UserProfile’s groups.

UserProfile >> addGroup: groupNameString
Add the UserProfileGroup with the given name to the receiver, and add the receiver to the UserProfileGroup.

UserProfile >> addToUserProfileGroup: aUserProfileGroup
Add the given UserProfileGroup to the receiver, and add the receiver to the UserProfileGroup.

Removing a user from a group

UserProfileGroup >> removeUser: aUserProfile
remove the given UserProfile from the receiver, and remove the receiver from this UserProfile’s groups.

UserProfile >> removeGroup: groupNameString
Remove the UserProfileGroup with the given name from the receiver, and remove the receiver from the UserProfileGroup.

UserProfile >> removeFromUserProfileGroup: aUserProfileGroup
Remove the given UserProfileGroup from the receiver, and remove the receiver from the UserProfileGroup.

Querying for Group members

UserProfileGroup >> users
Return a set of UserProfiles that belong to the receiver.

UserProfileGroup >> userIds
Return a set of UserIds for the UserProfiles that belong to the receiver.

Querying for a User’s Groups

UserProfile >> groups
Return the set of UserProfileGroups that this user belongs to.

UserProfile >> groupNames
Return the group names for each UserProfileGroup that this user belongs to.

for example:

topaz 1> printit

! Create group

UserProfileGroup newGroupWithName: 'Sales'.

System commitTransaction.

! Add users

(UserProfileGroup groupWithName: 'Sales') 

	addUser: (AllUsers userWithId: 'DataCurator');

	addUser: (AllUsers userWithId: 'GcUser').

! report the UserIds in that group

(UserProfileGroup groupWithName: 'Sales') userIds

%

anIdentitySet( 'DataCurator', 'GcUser')

Users Changing Their Own Password

Privileges required: UserPassword, and the account must be using GemStone authentication.

In many cases, users set their own passwords and may be required to update them periodically. These users must be given the UserPassword privilege to do so, and use the method UserProfile >> oldPassword:newPassword: to update their password.

For example:

System myUserProfile

	oldPassword: 'oldPasswordString'

	newPassword: 'newPasswordString'.

Password choice is constrained by login security that is configured for the repository; see the discussion under Limiting Choice of Passwords.

The new password takes effect when you commit the current transaction.

A different method, requiring other privileges, is used by Administrators to update the password of another user.

Changing Another User’s Password

Privileges required: OtherPassword, and the other user must be using GemStone authentication.

To modify the password of any GemStone user, execute the following expression.

(AllUsers userWithId: 'theUserId')

	password: 'newPasswordString' .

The new password takes effect when you commit the current transaction.

The password set by this method is not subject to the constraints described under Limiting Choice of Passwords, because this method can only be used by a user having the OtherPassword privilege. The password must not be the same as the UserId and must not be longer than 1024 characters.

Each password change of this type is noted in the GemStone security log, which currently is the Stone’s log file. The entry includes the userId of the session making the change but not the new password.

Determining Who Is Authorized to Read or Write in an Object Security Policy

Privileges required: read authorization for the security policy that controls access to this security policy, such as the DataCuratorObjectSecurityPolicy.

You can find out who is authorized to read or write objects in an security policy by sending it the message asString.For instance:

topaz 1> printit

PublishedObjectSecurityPolicy asString

%

anObjectSecurityPolicy, Number 6 in Repository SystemRepository,

Owner SystemUser write, Group Subscribers read, Group Publishers

write, World none

Changing the Authorization of an Object Security Policy

Privileges required: ObjectSecurityPolicyProtection or be the security policy’s owner, and write authorization to the DataCuratorObjectSecurityPolicy.

The new authorization will take effect for logins following the commit of the current transaction.

CAUTION
Do not attempt to change the authorization of SystemObjectSecurityPolicy.

To change the authorization for a security policy, execute any (or all) of the following expressions.

theObjectSecurityPolicy ownerAuthorization: #authSym.

theObjectSecurityPolicy worldAuthorization: #authSym.

theObjectSecurityPolicy group: groupOrGroupString authorization: #authSym.

NOTE
Exercise caution when changing the authorization for any security policy that a user may be using as his or her default or current security policy — whether or not the user owns the affected policy. If a user attempts to commit a transaction, but has created objects with a policy for which he or she no longer has write authorization, an error will be generated.

For example, to authorize the group Accounting to read (but not write) in user Eli’s default security policy, you could execute the following expression:

(AllUsers userWithId: 'Eli') defaultObjectSecurityPolicy

	group: 'Accounting'

	authorization: #read.

If the group 'Accounting' does not exist, GemStone will return an error. See under Create a group for information on creating a new group.

Remove a Group from an Object Security Policy’s Authorization List

Privileges required: ObjectSecurityPolicyProtection, and write authorization for the security policy.

To remove a group from a security policy’s list of authorized groups, execute an expression similar to the following:

theSecurityPolicy group: 'groupOrGroupString' authorization: #none

Change a User’s Default Object Security Policy

Privileges required: DefaultObjectSecurityPolicy, and write authorization to the DataCurator ObjectSecurityPolicy.

Changes to another user’s default security policy do not take effect until the next login.

To change a user’s default security policy, execute the following expression:

(AllUsers userWithId: 'theUserId') 

	defaultObjectSecurityPolicy: aNewSecurityPolicy

NOTE
If you change any user’s default security policy (including your own) to a security policy for which that user lacks write authorization, and you subsequently commit the transaction, the affected user will no longer be able to log in to GemStone.

Examining a User’s Privileges

No privileges are required for this operation.

GemStone provides messages that allow you to determine which privileged methods a GemStone user may execute, and to change the privileges of any user. Naturally, you need the appropriate privileges to use those methods.

To find out which privileged methods a given user is permitted to execute, send the following message to the desired user’s UserProfile:

(AllUsers userWithId: 'theUserId') privileges

This message returns an Array of Symbols. Table 8.1 lists the Smalltalk operations controlled by each privilege.

Adding a Privilege

Privileges required: OtherPassword and write authorization to the ObjectSecurityPolicy of the user’s UserProfile.

The new privileges will take effect when you commit the current transaction.

To add to a user’s existing privileges, execute the following expression:

(AllUsers userWithId: 'theUserId') addPrivilege: aPrivilegeSym.

Here’s an example that assigns three new privileges to user Bob:

topaz 1> printit

(AllUsers userWithId: 'Bob')

	addPrivilege: #SystemControl;

	addPrivilege: #SessionAccess;

	addPrivilege: #UserPassword .

System commitTransaction

%

Revoking a Privilege

Privileges required: OtherPassword and write authorization to the security policy of the user’s UserProfile.

The privileges will be revoked when you commit the current transaction.

To revoke one (or more) of a user’s existing privileges, execute the following expression:

(AllUsers userWithId: 'theUserId') deletePrivilege: aPrivilegeSym.

The following example revokes two of user Jane’s privileges:

topaz 1> printit

(AllUsers userWithId: 'Jane')

	deletePrivilege: #SystemControl;

	deletePrivilege: #SessionAccess.

System commitTransaction

%

Reassigning All Privileges

Privileges required: OtherPassword and write authorization to the security policy of the user’s UserProfile.

The new privileges will take effect when you commit the current transaction.

To redefine the full set of a user’s privileges, perhaps adding some and revoking others, execute the following expression:

(AllUsers userWithId: theUserId) privileges: anArrayOfSym 

This expression supersedes any previous privilege assignments. After the change is committed, only those privileges listed in the expression are valid for the user. Any privileges that were previously valid, but are not listed, are revoked.

For example:

topaz 1> printit

(AllUsers userWithId: 'Sam') privileges: 

	#( UserPassword ) .

System commitTransaction

%

Adding a SymbolDictionary to Your Own Symbol List

Privileges required: CodeModification.

You can add a dictionary to a symbol list by sending the message UserProfile>>insertDictionary: aSymbolDictionary at: anIndex. This change will affect other sessions that are logged in as this user when the other session commits or aborts, unless the other session is using a transient symbol list.

This example inserts dictionary NewDict (which already exists in the Published dictionary) into the user’s own symbol list:

topaz 1> printit

System myUserProfile

	insertDictionary: NewDict at: 2.

%

Inserting the new dictionary at index 2, as in the example, places it between the UserGlobals and the Globals dictionaries in the search order. Because symbol resolution depends on the order of dictionaries in a user’s symbol list, the index used in this example may not be appropriate for all situations.

Adding a SymbolDictionary to Someone Else’s Symbol List

Privileges required: OtherPassword and write permission to the security policy of the other user’s SymbolDictionary.

This example inserts dictionary NewDict (which already exists in the Published dictionary) into user Jerry’s symbol list:

topaz 1> printit

(AllUsers userWithId: 'Jerry')

	insertDictionary: NewDict at: 7.

System commitTransaction

%

Removing a SymbolDictionary from Your Own Symbol List

Privileges required: CodeModification.

You can remove a dictionary from a symbol list by sending the message UserProfile>>removeDictionary: aSymbolDictionary.

This example removes dictionary OldDict from the user’s own symbol list:

topaz 1> printit

System myUserProfile

	removeDictionary: OldDict.

System commitTransaction

%

Removing a SymbolDictionary from Someone Else’s Symbol List

Privileges required: OtherPassword and write permission to the security policy of the other user’s SymbolDictionary,

This example removes dictionary OldDict from user Jerry’s symbol list:

topaz 1> printit

(AllUsers userWithId: 'Jerry')

	removeDictionary: OldDict.

System commitTransaction

%

Explicitly Disable an Account in GemStone

Privileges required: OtherPassword. Logins cannot be disabled for special system accounts.

Users using any authentication scheme can be disabled using the methods disable or disableWithReason:. This prevents the user from logging in again, but does not affect currently logged in sessions.

For example:

topaz 1> printit

(AllUsers userWithId: 'Sam') 

	disableWithReason: 'on Sabbatical'.

System commitTransaction

%

Re-enable an Account that is using GemStone authentication

Privileges required: OtherPassword.

To re-enable an account that uses GemStone authentication, an administrative user must login and reset the users’s password. An account that becomes disabled, whether explicitly disabled or from security violations, will clear its password.

Users using GemStone authentication can be re-enabled using the methods password: or reenableWithPassword:.

For example, to reset Sam’s password and require him to change his password the first time he logs in:

topaz 1> printit

(AllUsers userWithId: 'Sam') 

	reenableWithPassword: 'AaBbCc';

	loginsAllowedBeforeExpiration: 1.

System commitTransaction

Re-enable an Account that is using external authentication

Accounts using external authentication rely on the security procedures for the external authentication scheme. If the external authentication disables logins, the user will not be able to login using GemStone, but the account in GemStone is not disabled.

Accounts that were explicitly disabled in GemStone can be re-enabled using the method reenable . Since the password is managed outside GemStone, you do not need to supply a new password.

topaz 1> printit

(AllUsers userWithId: 'Mary') reenable.

System commitTransaction

Find Out Which Accounts Have Been Disabled in GemStone

Privileges required: OtherPassword.

The message AllUsers findDisabledUsers returns a SortedCollection of UserProfiles that were either disabled explicitly, or that use GemStone authentication and were disabled by a security precaution such as password expiration, login failure, etc. Accounts using external authentication and that have been disabled by the rules for that authentication are not disabled in GemStone, and will not be returned by this method.

For example:

topaz 1> printit

AllUsers findDisabledUsers 

  collect: [:aUser | aUser userId ] .

%

an Array

  #1 Sam

  #2 Mary

See Re-enable an Account that is using GemStone authentication for how DataCurator or another user with the OtherPassword privilege can reactivate an account.

Check If an Account Is Disabled

Privileges required: OtherPassword.

You can check if a particular account is disabled in GemStone by sending the message isDisabled to the account’s UserProfile.

For example:

topaz 1> printit

(AllUsers userWithId: 'Sam') isDisabled

%

true

Find Out Why an Account Was Disabled

Privileges required: OtherPassword.

You can find out why a particular account was disabled in GemStone by sending the message reasonForDisabledAccount to the account’s UserProfile.

For example:

topaz 1> printit

(AllUsers userWithId: 'Sam') reasonForDisabledAccount

%

LoginsWithSamePassword

If the account was disabled using the method disableWithReason:, this method will return that argument. Otherwise if the account was disabled by login security, it will return one of these Strings: 'PasswordAgeLimit', 'StaleAccount', 'LoginsWithSamePassword', or 'LoginsWithInvalidPassword'.

Disable Commits

Privileges required: OtherPassword. Commits cannot be disabled for special system users.

To disable commits for a user, execute the following expression:

(AllUsers userWithId: theUserId) disableCommits

This expression disables any commits for the given user, beginning with the next login of the user after the session making this change commits. If this user is currently logged in, it does not affect the user’s session/s.

For example:

topaz 1> printit

(AllUsers userWithId: 'Sam') disableCommits.

System commitTransaction

%

Re-enable Commits for a User

Privileges required: OtherPassword.

To enable commits for a user, execute the following expression:

(AllUsers userWithId: theUserId) enableCommits

This expression enables commits for the given user, beginning with the next login after the session making this change commits.

Check If a User Can Commit

Privileges required: OtherPassword or ReadOtherUserProfile.

To test if commits have been disabled for a user account, execute the following expression:

(AllUsers userWithId: theUserId) isReadOnly

Disallow All Previously Used Passwords

To disallow password reuse, use the method:

AllUsers disallowUsedPasswords: aBoolean.

Disallow a Specific Number of Previous Passwords

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy.

To disallow a fixed number of previously-used password, but allow earlier passwords, use the following:

AllUsers numberOfDisallowedPasswords: anInteger

anInteger must be a number between 0 and 65535; 0 means that the user may not reuse any previously-used passwords. The limit on the number of disallowed passwords has no effect if disallowUsedPasswords is false.

For example:

AllUsers disallowUsedPasswords: true.

AllUsers numberOfDisallowedPasswords: 10.

Clearing a User’s Disallowed Old Passwords

Privileges required: OtherPassword.

You can clear the set of old passwords so that they can be reused. As mentioned above, this set is maintained for each user when the AllUsers instance variable disallowUsedPasswords is set to true.

The following example clears the remembered passwords for Mary’s account:

(AllUsers userWithId: 'Mary') 

	clearOldPasswords.

Repository-Wide Password Aging

You can require users to change their password periodically by setting up a password age limit. This can be set for all users in the repository, and can be overridden for specific individual users.

To set a password page limit for all users in the repository, for example to 120 days:

AllUsers passwordAgeLimit: 120 * 24 .

The passwordAgeLimit is added to the time the password was last changed to determine when the password will expire. A setting of 0 (the default) disables password aging.

Each time this method is invoked, the action is recorded in the Stone’s log.

If a user does not change the account’s password within the specified interval, the account is disabled, and attempts to log in result in an error.

DataCurator or another user with the OtherPassword privilege can reactivate the disabled account by giving it a new password; see Re-enable an Account that is using GemStone authentication for details.

Password Age Limits for Individual Users

To override the repository-wide setting for password aging, you can set a password age limit for a specific user. For example, to set the limit for a Mary to 5 days:

(AllUsers userWithId: 'Mary') 

	passwordAgeLimit: 5 * 24.

If repository-wide password aging is enabled, you can also override this for individual users, such as managers or administrators, either by setting the password page limit to 0, or setting the password to never expire. For example, to prevent the password used by batch jobs from expiring, execute:

(AllUsers userWithId: 'BatchUser') 

	setPasswordNeverExpires: true.

Repository-Wide Password Expiration Warning

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy. This does not apply to system users, and has no effect if password aging is not enabled.

You can provide an automatic warning to users repository-wide whose password is about to expire. For example, to warn users who log in within five days of the time their password will expire, do this:

AllUsers passwordAgeWarning: 5 * 24.

Logins within numberOfHours prior to expiration cause a SecurityError to be signaled.

Per-User Password Expiration Warning

You can provide a similar automatic warning to a specific user. For example, to warn Mary within three days of the time her password will expire, do this:

(AllUsers userWithId: 'Mary') passwordAgeWarning: 3 * 24.

Finding Accounts with Password About to Expire

Privileges required: OtherPassword.

You can find out which accounts have a password within the warning period set by passwordAgeWarning:. To do this, send the message findProfilesWithAgingPassword to AllUsers. For example:

topaz 1> printit

AllUsers findProfilesWithAgingPassword 

  collect: [ :u | u userId] .

%

an OrderedCollection

#1 qa1

#2 qa2

#3 qa3

Finding Out When a Password Was Changed

Privileges required: OtherPassword or ReadOtherUserProfile.

You can find out the last time the password was changed for a particular userId by sending the message lastPasswordChange to that account’s UserProfile. This example converts the DateTime returned to a particular pattern based on MM/DD/YY:

topaz 1> printit

(AllUsers userWithId: 'qa2') lastPasswordChange US12HrFormat

%

08/04/23 11:28 AM

Repository-Wide Stale Account Aging

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy. The special GemStone accounts are not disabled by stale account aging.

To do this, send the message staleAccountAgeLimit: numberOfHours to AllUsers. This example disables accounts when they have not logged in for 30 days:

AllUsers staleAccountAgeLimit: 30 * 24.

Each time this method is invoked, the action is recorded in the Stone log.

A setting of 0 (the default) disables account aging.

DataCurator or another user with the OtherPassword privilege can reactivate the disabled account by giving it a new password; see Re-enable an Account that is using GemStone authentication for details.

Per-User Stale Account Aging

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy. The special GemStone accounts are not disabled by stale account aging.

You can override the repository-wide setting for account aging for a specific user using UserProfile>>staleAccountAgeLimit: numberOfHours.

For example, for the ‘Auditor’ account who may log in less frequently, you can set up a 180-day stale account age limit. This will override a repository-wide 30 day setting.

(AllUsers userWithId: 'Auditor') 

	staleAccountAgeLimit: 180 * 24.

Finding Out When an Account Last Logged In

Privileges required: OtherPassword or ReadOtherUserProfile.

If at least one age limit applies to an account, you find out when that account last logged in by sending the message lastLoginTime to that account’s UserProfile. For example:

topaz 1> printit

(AllUsers userWithId: 'Mary') lastLoginTime US12HrFormat

%

08/04/23 01:40 PM

The time of the last login is maintained only if loginsAllowedBeforeExpiration is set in that UserProfile or if at least one of these instance variables is set in AllUsers or the specific UserProfile: passwordAgeLimit, passwordAgeWarning, or staleAccountAgeLimit. If none of these features are enabled, the lastLoginTime may be nil, the time of the account creation, or a time representing a login during an earlier period when one of these features was enabled. This is also true if a feature that enables lastLoginTime recording has been enabled on more recently than the last login of the user.

The data curator may explicitly set the time of the last login, using the method UserProfile >> lastLoginTime:.

Record Login Failures

The Stone repository monitor keeps track of login failures (incorrect passwords) for each account and can write that information to the Stone’s log.

By default, messages are logged when the same account fails login attempts 10 or more times within ten minutes. You can change the default limits by setting the STN_LOG_LOGIN_FAILURE_LIMIT and STN_LOG_LOGIN_FAILURE_TIME_LIMIT configuration options.

The log message gives the following information:

---Mon 07 Aug 2023 09:39:40 PDT ---

    GemStone user Mary has failed on 10 attempt(s) 

       to log in within 1 minute(s).

    The last attempt was from user account writer1 on hostname docs.

Disabling Further Login Attempts

If login failures continue, the Stone repository monitor can disable the account. By default, the account is disabled when the number of failures exceeds 15 within 15 minutes. You can change the default limits by setting the STN_DISABLE_LOGIN_FAILURE_LIMIT and (STN_DISABLE_LOGIN_FAILURE_TIME_LIMIT configuration options.

Subsequent attempts to login as that account result in the following error message:

Login failed:  the GemStone userId/password combination is invalid or expired.

The special user accounts are not disabled by login failures.

DataCurator or another user with the OtherPassword privilege can reactivate the disabled account by giving it a new password; see Re-enable an Account that is using GemStone authentication for details.

Explicit mode

System validatePasswordUsingLdapServers: 

		(Array with: 'ldaps://myldap.mydomain.com')

	baseDn: 'uid=%s,ou=Users,dc=mycompany,dc=com' 

	filterDn: nil

	userId: 'MyUserId' password: 'swordfish' 

	bindDn: nil bindPassword: nil

Search mode with anonymous bind

System validatePasswordUsingLdapServers: 

		(Array with: 'ldaps://myldap.mydomain.com')

	baseDn: 'ou=Users,dc=mycompany,dc=com' 

	filterDn: '(uid=%s)'

	userId: 'MyUserId' password: 'swordfish' 

	bindDn: nil bindPassword: nil

Search mode with authenticated bind

System validatePasswordUsingLdapServers: 

		(Array with: 'ldaps://myldap.mydomain.com')

	baseDn: 'ou=Users,dc=mycompany,dc=com' 

	filterDn: '(uid=%s)'

	userId: 'MyUserId' password: 'swordfish' 

	bindDn: 'LdapBindUser' bindPassword: 'LdapBindPassword'

For further details, see the method comments in the image.

LdapDirectoryServers with TLS

To control the TLS options from GemStone rather than from LDAP configuration files, use protocol on LdapDirectoryServer. This is required when the process is in setuid mode.

You can create the LdapDirectoryServer, specifying the certificate, CA certificate, and key using the following method:

LdapDirectoryServer class >> newWithUri: uri bindDN: aBindDn password: password baseDN: baseDn tlsCaCert: caCert tlsCert: cert tlsKey: key tlsReqCert: tlsChecksSymbol

tlsChecksSymbol is a symbol which specifies what checks to perform on server certificates in a TLS session, if any. The following symbols are recognized:

#never - The client will not request or check a server certificate.

#allow - The server certificate is requested. if not provided or if the certificate is invalid, it is ignored and the session proceeds normally.

#try - the server certificate is requested. If not provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated.

#demand (the default) - the server certificate is requested; if not provided or if the certificate is invalid, the session is immediately terminated.

You can validate a password using the LdapDirectoryServer method:

LdapDirectoryServer >> validatePassword: aPassword forUserId: aUserId withBaseDn: aBaseDn filterDn: aFilterDn

The method comments for this method includes examples of using this method; see the image for details.

Create an instance of KerberosPrincipal for the specific User

A UserProfile who will use SSO is associated with a specific instance of KerberosPrincipal. For example, to create a Kerberos user principle for the GemStone user named Mary, use an expression such as this:

KerberosPrincipal 

	newPrincipalWithName: 'maryb@BIGCORPORATION.COM' 

	loginUserProfile: (AllUsers userWithId: 'Mary').

This creates the KerberosPrincipal and adds it to AllKerberosPrincipals.

Enable SingleSignOn for this UserProfile using the new KerberosPrincipal

Use the Kerberos Principle when enabling SingleSignOn, using UserProfile >> enableSingleSignOnAuthenticationWithPrincipal:.

Configure the Gem’s environment for the client application to set the keytab file location

The Gem configuration parameter GEM_KERBEROS_KEYTAB_FILE must be set in order to specify the location of the keytab file.

For example:

GEM_KERBEROS_KEYTAB_FILE ='/export/localnew/common/kerberos/gemtalk.keytab';

You may enter this in the configuration file that will be used by Gem sessions. This may be the default $GEMSTONE/data/system.conf, or another configuration file, as described starting here.

| prin user |

user := AllUsers userWithId: 'Mary'.

prin := KerberosPrincipal 

	newPrincipalWithName: 'maryb@GEMTALKSYSTEMS.COM' 

	loginUserProfile: user.

user enableSingleSignOnAuthenticationWithPrincipal: prin.

System commitTransaction.

Ensure Kerberos is setup and the specific user has a ticket on the client application

On the client application that will login (for example, topaz; or a client Smalltalk such as VisualWorks), get a Kerberos ticket. On UNIX, this is done via kinit. On Windows, the ticket automatically comes from the Windows domain login. The windows session must be logged into a windows domain, controlled by a Windows domain controller or a samba domain controller; Windows clients not on a domain cannot do SSO.

Verify login without password

Verify authentication; login as the user account, leaving the password empty, and confirm the login succeeds. To verify that maryb is authenticated using Kerberos, enter the GemStone user name (Mary) in the login parameters, and leave the password empty.

Example 8.2 Setting up SingleSignOn using Groups

| prin user1 user2 group |

user1 := AllUsers userWithId: 'john'.

user2 := AllUsers userWithId: 'mary'.

group := UserProfileGroup 

	newGroupWithName: 'KerberosAdminLogin'.

user1 addGroup: group groupName.

user2 addGroup: group groupName.

prin := KerberosPrincipal newPrincipalWithName:

	'jsmith@GEMTALKSYSTEMS.COM' loginUserProfile: nil.

prin addGroup: group.

group users do: [:aUserProfile | aUserProfile

	enableSingleSignOnAuthenticationWithPrincipal: prin].

System commitTransaction.

Example 8.3 Sharing a KerberosPrincipal

| prin user1 user2 |

user1 := AllUsers userWithId: 'Mary'.

user2 := AllUsers userWithId: 'John'.

prin := KerberosPrincipal 	newPrincipalWithName:

	'jsmith@GEMTALKSYSTEMS.COM' 	loginUserProfile: nil.

prin loginAsAnyoneEnabled: true.

user1 enableSingleSignOnAuthenticationWithPrincipal: prin.

user2 enableSingleSignOnAuthenticationWithPrincipal: prin.

System commitTransaction.

Example 8.4 Using GsExternalSession to perform a second login

DataCurator or a administrative user must give this user the #CreateOnetimePassword privilege. For example, to allow a user with the UserId 'Mary' to login a second session without re-entering a password:

(AllUsers userWithId: 'Mary') 

	addPrivilege: 'CreateOnetimePassword'.

System commitTransaction.

Then, 'Mary' can login, and create a temporary password. Since the secondary login will be the same UserProfile, this does not need to be specified when creating the temporary password, and the default in the session can be used.:

tempPW := GsCurrentSession currentSession

createOnetimePasswordValidForSeconds: 30. 

To use this password to login an external session:

sess := (GsTsExternalSession newDefault)

onetimePassword: tempPW;

yourself.

sess login.

Example 8.5 Using GsExternalSession to perform a login as SubordinateUser

The following example allows DataCurator to login a session as the UserProfile with userId 'Mary'.

First, DataCurator adds 'Mary' to their allowlist:

System myUserProfile addOnetimePasswordUserId: 'Mary'.

System commit.

Then, a temporary password is created:

tempPW := GsCurrentSession currentSession

createOnetimePasswordForUserId: 'Mary'

validForSeconds: 30. 

To use this password to login an external session:

sess := (GsTsExternalSession newDefault)

username: 'Mary';

onetimePassword: tempPW;

yourself.

sess login.