6. User Accounts and Security

SystemUser

SystemUser is analogous to root in UNIX. SystemUser has all 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.

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. 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. You normally would only login as GcUser in order to update configuration parameters stored in GcUser’s UserGlobals.

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. Do not use this account or change it unless instructed to do so by GemStone Technical Support.

User ID

Each UserProfile is created with a unique user Id String. Embedded spaces are permitted.

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

Password

Each UserProfile is created with an initial password, an Invariant String, which must not be the same as the User Id and may not be longer than 1024 characters. The user supplies this password for identification purposes at login, unless another form of login authentication is used; see Password Authentication.

Users must have the explicit privilege #UserPassword to change their own passwords, and there are a number of ways to constrain the choice of passwords. See the section Limiting Choice of Passwords for details.

To change the password of a user other than yourself, the #OtherPassword privilege is required, a different method is used, and password constraints do not apply.

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.

To specify a defaultObjectSecurityPolicy for a user, you may use an existing instance of GsObjectSecurityPolicy, or you must create and commit the GsObjectSecurityPolicy before it can be used.

To modify the defaultObjectSecurityPolicy of any user, you must have write access to the security policy of that UserProfile. In addition, to modify your own defaultObjectSecurityPolicy, you must have the DefaultObjectSecurityPolicy privilege.

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 6.1 describes the types of functions that each privilege controls.

For developers, you must also specifically grant the privilege that allows the user to modify code.

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.

Groups

GemStone uses group membership to facilitate access to objects that are protected by GsObjectSecurityPolicies. While certain objects must be protected from read or write access by other users in the system (the “world”), you may still need to grant access to specific individual users. By adding group authorization to the GsObjectSecurityPolicy that protects these objects, and adding the corresponding group membership to that user, you can provide a user with the appropriate access to these objects.

A GsObjectSecurityPolicy can authorize multiple groups and a user can be a member of multiple groups. There are several predefined groups, as shown in Table 6.2. By default, all new users become members of group Subscribers.

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

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'

	createNewObjectSecurityPolicy: 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 groups, and specify an ObjectSecurityPolicy. The ObjectSecurityPolicy may be nil.

AllUsers addNewUserWithId: 'theUserId'

    password: 'thePassword'

    defaultObjectSecurityPolicy: anObjectSecurityPolicyOrNil

    privileges: anArrayOfPrivStrings

    inGroups: aCollectionOfGroupStrings

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.

DeletedUserProfile and AllDeletedUsers

When a user is removed, a new instance of DeletedUserProfile is created, with the userId and the SymbolLists of the user being removed, and the current DateTime.

This instance of DeletedUserProfile is moved to a collection #AllDeletedUsers, in Globals SymbolDictionary.

An administrator should review the classes and methods in the SymbolLists of the DeletedUserProfile, copy anything valuable elsewhere, and manually remove the DeletedUserProfile from AllDeletedUsers.

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

This form passes in the instance of UserProfile for the user to be deleted:

AllUsers removeAndCleanup: aUserProfile.

While this form passes in the userId of the user to be deleted, and includes a block to execute if no UserProfile with the given userId exists in AllUsers:

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.

This form passes in the instance of UserProfile for the user to be deleted and the UserProfile to which to reassign the ObjectSecurityPolicies:

AllUsers removeAndCleanup: aUserProfile

	migrationSecurityPoliciesTo: anotherUserProfile.

While this form passes in the userId String of the user to be deleted and the userId String of the UserProfile to which to reassign the ObjectSecurityPolicies, and includes a block to execute if a UserProfile does not exist with either of the UserId Strings:

AllUsers removeAndCleanupUserWithId: ‘aUserId’

	migrationSecurityPoliciesUserWithId: ‘anotherUserId’

	ifAnyAbsent: aBlock

For example,

topaz 1> printit

AllUsers removeAndCleanup: (AllUsers userWithId: 'John')

	migrationSecurityPoliciesTo: (AllUsers userWithId: 'Ann')

System commitTransaction.

Users Changing Their Own Password

Privileges required: UserPassword.

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.

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 with which this policy is associated, 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: #anAuthorizationSymbol.

theObjectSecurityPolicy worldAuthorization: #anAuthorizationSymbol.

theObjectSecurityPolicy group: 'aGroupString'

	authorization: #anAuthorizationSymbol.

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. The discussion under Adding a User to a Group“explains how to create a new GemStone 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: 'aGroupString' 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 Group Memberships

No privileges are required for this operation.

To find out which groups a user belongs to, execute the following expression:

(AllUsers userWithId: 'theUserId') groups

This expression returns a Set of Strings indicating the groups to which the user belongs.

Adding a User to a Group

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy.

To add a user to a group, do the following:

('MarathonRunners' in: AllGroups)

	ifFalse: [AllGroups add: 'MarathonRunners' ].

(AllUsers userWithId: 'theUserId') addGroup: 'MarathonRunners'.

This expression adds the user to the group MarathonRunners by adding the group name to the list of groups maintained in the UserProfile. (This action takes effect when you commit the current transaction.)

If the group MarathonRunners did not previously exist, this expression creates it in AllGroups (the “master list” of all group names). See AllGroups for more information.

Removing a User from a Group

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy.

To remove a user from a group, execute an expression of the following form:

(AllUsers userWithId: 'theUserId') removeGroup: 'Sprinters'.

This expression removes the designated group from the list of groups to which the user belongs. This action will take effect when you commit the current transaction. For more information about groups, see the Security chapter of the Programming Guide.

Listing Members of a Group

No privileges are required for this operation.

To list all members of a user group, execute an expression of the following form:

AllUsers membersOfGroup: aString

This expression returns an IdentitySet containing the userId for each member of the group.

Removing a Group

Privileges required: OtherPassword and write authorization to DataCuratorObjectSecurityPolicy.

To remove a user group from the global object AllGroups, first remove each member from the group, then remove the group itself, using the expression

AllGroups removeGroup: aGroupString. 

For example, to remove a group named MarathonRunners:

topaz 1> printit

  "Remove each member from the group "

(AllUsers usersInGroup: 'MarathonRunners') do:

        [:aUserProfile| aUserProfile removeGroup: theGroup]. 

  "Now remove the group itself "

AllGroups remove: 'MarathonRunners'.

System commitTransaction

%

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 Strings. Each String in the Array corresponds to one of the user’s privileges. Table 6.1 lists the Smalltalk methods that correspond to 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: aPrivilegeString .

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: aPrivilegeString.

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: anArrayOfStrings 

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. The change does not affect the transient copy of the symbol list that is used by another currently logged in session until that session commits or aborts.

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.

The change does not affect the transient copy of the symbol list that is used by another currently logged in session, until that session commits or aborts.

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

%

Disable an Account Explicitly

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

Users can be disabled using the method disable or disableWithReason:. This prevents the user from logging in, but does not affect current login sessions.

For example:

topaz 1> printit

(AllUsers userWithId: 'Sam') 

	disableWithReason: 'on Sabbatical'.

System commitTransaction

%

Re-enable an Account

Privileges required: OtherPassword.

To re-enable a user account, an administrative user must login and reset the users’s password. 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') 

	password: 'AaBbCc';

	loginsAllowedBeforeExpiration: 1.

System commitTransaction

%

Find Out Which Accounts Have Been Disabled

Privileges required: OtherPassword.

The message AllUsers findDisabledUsers returns a SortedCollection of UserProfiles that are disabled explicitly or by one of the security precautions discussed in this chapter:

• The password expired (through aging or a login limit).
• The account remained inactive.
• There were repeated password failures.

For example:

topaz 1> level 1

topaz 1> printit

AllUsers findDisabledUsers 

  collect: [:aUser | aUser userId ] .

%

an Array

  #1 qa2

  #2 qa3

DataCurator or another user with the OtherPassword privilege can reactivate an account by giving it a new password, as described under Changing Another User’s Password.

Check If an Account Is Disabled

Privileges required: OtherPassword.

You can check if a particular account is disabled by sending the message isDisabled to the account’s UserProfile. The method returns either True or False. This example inquires about account qa2:

topaz 1> printit

(AllUsers userWithId: 'qa2') isDisabled

%

true

Find Out Why an Account Was Disabled

Privileges required: OtherPassword.

You can find out why a particular account was disabled by sending the message reasonForDisabledAccount to the account’s UserProfile. This example inquires about account qa2:

topaz 1> printit

(AllUsers userWithId: 'qa2') 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 transaction, if any.

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.

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

(AllUsers userWithId: theUserId) isReadOnly

UserId or Alias

As with UNIX authentication, if the LDAP userId is the same as the GemStone Id, you may pass in nil for the argument UNIXUserIdOrNil; otherwise, pass in the LDAP userId. The user will use their GemStone userId and the password for their LDAP account to log in.

Fully Qualified DN

You can configure the LDAP authentication for a particular user with the specific DN, with ‘%s’ replacing the userId, for the baseDn: argument. In this case you should pass in nil for the filterDn: argument, which will disable the query.

For example, to configure authentication to use a specific fully qualified DN:

topaz 1> printit

(AllUsers userWithId: 'Mary') 

	enableLDAPAuthenticationWithAlias: 'msmith'

	baseDn: 'uid=%s,ou=employees,dc=somecompany,dc=com' 

	filterDn: nil.

System commitTransaction.

%

Search for DN

You can also configure authentication to include the base domain information in the baseDn: argument, and include a filter in the filterDn: argument. The filter must contain ‘%s’ in the position for the userId. GemStone will perform a query to get the full DN given the base and filter information.

The base and filter information is provided at the time the authentication is configured, not at login time, so a search option is particularly useful if the LDAP structure is likely to be modified.

To configure authentication to do a search for the given user:

topaz 1> printit

(AllUsers userWithId: 'Mary') 

	enableLDAPAuthenticationWithAlias: 'msmith'

	baseDn: 'dc=somecompany,dc=com'

	filterDn: '(uid=%s)'.

System commitTransaction.

%

LDAP authentication without anonymous binds

By default, GemStone login authentication requires that the LDAP server allow anonymous binds. For installations that disallow anonymous binds, you may configure instances of LdapDirectoryServer with the information required for authenticated binds.

AllLdapDirectoryServers is a global collection of instance of LdapDirectoryServer. Each instance of LdapDirectoryServer contains authentication information for an particular LDAP server.

During login, If there are existing instances of LdapDirectoryServer in AllLdapDirectoryServers, then these are used, in order; normally this would include a primary LDAP server and an alternate. If and only if the bind to the first LDAP server fails, the second is tried, and so on. If no binds are successful, then the login will fail.

If AllLdapDirectoryServers is empty, then login will use anonymous bind.

To create an LdapDirectoryServer, and add it to the global list, use the following method:

LdapDirectoryServer class >> newWithUri: uri bindDN: aBindDn

	password: password

If LDAP authentication is setup, using

enableLDAPAuthenticationWithAlias: aString baseDn: baseDn filterDn: filterDn

then either anonymous or authenticated binds are performed to authenticate the user password.

For example, to set up a user to use LDAP authentication, and setup a single LDAP server to authenticate binds, the following code would be executed.

aUserProfile 

	enableLDAPAuthenticationWithAlias: nil

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

	filterDn: '(uid=%s)' .

LdapDirectoryServer 

	newWithUri: 'ldaps://ldap.gemtalksystems.com'

	bindDN: 'uid=bindUser,ou=Users,dc=gemtalksystems,dc=com'

	password: 'swordfish' .

Users are individually configured to use LDAP authentication, but LDAP directories are configured for the repository as a whole, so this step is only done once. All users use the same bind authentication, though they use their own individual passwords to perform the actual account authentication.

Note that the instances of LdapDirectoryServer store the encrypted bind password. This is not the actual user password to login to GemStone; this bind password allows you to perform the user password authentication.

To determine if a particular LdapDirectoryServer exists, use the following method, which returns either the LdapDirectoryServer or nil if it is not found:

LdapDirectoryServer >>findServerWithUri: aUriString

to remove an LdapDirectoryServer, use the method:

LdapDirectoryServer >> removeServerWithUri: aUriString

Validating passwords

Once logged in, you can perform an validation call to the LDAP server that passes in the LDAP authentication as well as the user authentication, using this method:

System class >> validatePasswordUsingLdapServers:baseDn:

	filterDn:userId:password:bindDn:bindPassword: 

The additional bind arguments should be nil if authenticating in explicit mode, or with anonymous bind. For example:

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

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

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'

Disallow All Previously Used Passwords

To disallow password reuse, use the method AllUsers disallowUsedPasswords: aBoolean.

For example:

topaz 1> printit

AllUsers disallowUsedPasswords: true .

System commitTransaction

%

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,

topaz 1> printit

AllUsers disallowUsedPasswords: true.

AllUsers numberOfDisallowedPasswords: 10.

System commitTransaction

%

Clearing a User’s Disallowed Old Passwords

Privileges required: OtherPassword.

You can clear the set of old passwords so that they can be reused by sending the message clearOldPasswords to that user’s UserProfile. 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:

topaz 1> printit

(AllUsers userWithId: 'Mary') clearOldPasswords.

System commitTransaction

%

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, use the method UserProfileSet>>passwordAgeLimit:numberOfHours.

For example, to set the limit to 120 days:

topaz 1> printit

AllUsers passwordAgeLimit: 120 * 24 .

System commitTransaction

%

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 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, by using the method UserProfile>>passwordAgeLimit:numberOfHours.

For example, to set the limit for a Mary to 5 days:

topaz 1> printit

(AllUsers userWithId: 'Mary') passwordAgeLimit: 5 * 24.

System commitTransaction

%

If repository-wide password aging is enabled, you can also override this for individual users, such as managers or administrators, either by setting the passwordAgeLimit for that UserProfile to 0, or by executing setPasswordNeverExpires: with a true argument.

For example, to prevent the password used by batch jobs from expiring, execute:

topaz 1> printit

(AllUsers userWithId: 'BatchUser') 

	setPasswordNeverExpires: true.

System commitTransaction

%

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 by sending the message UserProfileSet>>passwordAgeWarning:numberOfHours. 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 specific user using UserProfile>>passwordAgeWarning:numberOfHours.

For example, to warn Mary within three days of the time her password will expire, do this:

topaz 1> printit

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

System commitTransaction

%

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.

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

%

04/06/15 11:28 AM

Repository-Wide 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 for details.

Per-User 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.

topaz 1> printit

(AllUsers userWithId: 'Auditor') 

	staleAccountAgeLimit: 180 * 24.

System commitTransaction

%

Finding Out When an Account Last Logged In

Privileges required: OtherPassword.

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

%

04/06/15 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:

---Fri 1 May 2015 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 for details.