 |
|
|
 | Privileges and Privilege Subjects | User Groups and Group Maintenance |  |
Data protection in the database is based on the user account principle. Each client logs in the database using some user account and is then granted certain privileges such as the privilege to read or write some data.
Each account is designated by a user name. User name may have a maximum of 31 characters and is not case-sensitive.
A user account usually represents only one person who accesses the database. An exception to that is the anonymous account - everyone may log in using this account (if it's enabled). You log in using the anonymous access with a empty name, or the ANONYMOUS name.
User accounts may be created by security or configuration administrators and be the users, who are granted the privilege to insert records into the system table USERTAB (DB_ADMIN group has this privilege too). The privilege to create new users doesn't allow you to assign users into groups. Use the CREATE USER SQL statement to create a user.
User accounts may be deleted by security, configuration or data administrators. A user who is logged in may also delete his own account. You can delete a user account by calling the DROP USER SQL statement.
When an account is deleted and then created again it's not the same user account - the privileges of the original user are lost. Thus the configuration administrator can't access the user's private data by simply deleting it and creating it again.
If the SQL server user login based on previous user login to a domain enabled, then you may enable automatic user creation - user accounts are then created after first login of each user to the SQL server.
You may create and delete users in the client developer interface - folder System / System objects / Users .
The information describing each user in more detail (name, surname etc.) may be set on user creation and later changed by the user himself. Noone else (except for the security or data administrators) may overwrite this information. A dialog window with the user data appears when you click on the Properties action from the popup of a selected user. The user may change his password here (the security administrator may change all passwords) however the present password cannot be read here.
You can check the User must change password on next login checkbox when editing the password - the original password is therefore valid only once and the user is prompted to specify a new password on the next login. This doesn't work for user with permanently valid password - see below.
If the user's name is changed, the user won't lose the granted privileges (as it's in the case of deleting and recreating).
When a client logs in the server using some user name, the server has to check its identity. It can be done as follows:
No database administrator may learn another's password. The security policy concerning user logins is also discussed here.
The password maintenance in 602SQL utilizes the one-time-password RFC1938 method. This method has this properties:
This method has one disadvantage - each password may be used only for a limited time - usually thousands of times. After exceeding this limit, 602SQL prompts the user to set a new password.
There is a class of applications that will experience complications if the users were forced to periodically change their passwords. This concerns mainly the noninteractive 602SQL clients, such as the CGI or PHP client. Therefore there's a possibility to use permanent passwords.
Permanent password are used for all user accounts beginning with the _ character (underline). E.g. some internet clients use the __WEB username.
The security administrator may decide whether all passwords will be permanent. This can be done in the Control Panel's Runtime parameters windows, Security tab.
The security administrator may specify a domain that can be trusted so any users who are connected to that domain will be trusted and allowed to connect to the SQL server. You have to set the domain's name in the Control Panel's Runtime parameters window, Security tab.
The name the user used to login to the domain must be the same as the account name in the database. Therefore it's recommended to create the user accounts by taking the names from the domain.
The security administrator may suspend the validity of a user account for some time - users can't login using this account until the validity is restored. Suspending and restoring account validity is done in the same window as the user information editing (see above) - checkbox Account disabled.
A special case is enabling or disabling of the anonymous account. The security administrator decides whether the anonymous account should be enabled or not. This property can be set in the Control panel's Runtime parameters window, Security tab.
If a user forgets the password, there's no way to find it. The user may then ask the security administrator to create a new password. It's not recommended to delete the account and create it again, because the user will lose all granted privileges.
Each user may change his password. Only the security administrator may change other user's passwords. You can change the password by calling the Set_password function or in the client interface from the window where you can edit user information (see above).
| Privileges and Privilege Subjects | User Groups and Group Maintenance | |