To avoid accidental data corruption HyperDoc implements the following mechanism. HyperDoc users need only read access to the HDocConfiguration table in the HyperDoc database. Users do not need any other rights in this table or any rights at all in other HyperDoc tables. HyperDoc logs in to the database using supplied user credentials. After logging in successfully, HyperDoc reads the account name and password of the special HyperDoc system account from the HDocConfiguration table and connects to database again using this account. The HyperDoc system account must have all the rights to all the tables HyperDoc uses, except for those data tables that are intended to be read-only. Since the password of the special HyperDoc system account stored in the HDocConfiguration table is encrypted, this mechanism prevents users from accessing HyperDoc data in any other way than through HyperDoc itself.
During the login to the database using supplied user credentials, HyperDoc checks if the user has the right to read HDocUserRights table. If so, the user is considered to be HyperDoc administrator, i.e. he can execute Logical Devices and Text Macros commands, he can view and assign user permissions with User Permissions command and security class permissions with Security Classes command. Ordinary user can only view his own rights in User Permissions and Security Classes commands. Both commands are available in HyperDoc and in HDAdmin utility.
There are five categories of HyperDoc database users:
1. Super User - the user who creates and configures HyperDoc database. He needs the right to create user accounts, to create tables, to assign database user rights and to read and write from all HyperDoc tables. 2. HyperDoc administrator - the user who assigns HyperDoc user permissions with User Permissions and Security Classes commands. By definition he has the right to read HDocUserRights table. He needs the right to read HDocConfiguration table. HyperDoc administrator can use HyperDoc and perform administrative tasks, like changing access rights, managing logical devices, text macros, etc. 3. HyperDoc system account. This user account needs the right to read all HyperDoc tables and to write to some of them, e.g. HDocParams, HDocDocSetObjects and so on. 4. Ordinary HyperDoc user - by definition he has the right to read HDocConfiguration table. 5. Foreign database user. He is a database user, who does not use HyperDoc. By definition he does not have the right to read HDocConfiguration table. He does not need any access rights to any HyperDoc tables.
Additional administrative utility HyperDoc Administrator (HDAdmin) is provided. Among other purposes, it can be used for HyperDoc system account management. If the password only has been changed, no other administrative tasks are needed, because HDAdmin makes password change known to the underlying database system (Microsoft Access, Microsoft SQL Server or Oracle Server). If the HyperDoc system account name has been changed, administrator must use appropriate administrative tools to make sure that this account exists. HDAdmin on start-up and on each system account change verifies if this account has all necessary rights to all HyperDoc tables. If these rights are not sufficient, it grants them automatically. The HyperDoc system account name and password are reserved for the system use and should be never used by HyperDoc users or administrators.
HyperDoc supports two login modes:
native database accounts mode using database list of logins (described above and used in most cases), proprietary user list mode using list of logins stored in HyperDoc configuration table HDocUsers. This mode allows many HyperDoc users share single database account and is available for ODBC databases only
HyperDoc on start-up, when configured for ODBC database, tries to find HDocCfg.DAT file in the following places:
- the directory where HyperDoc is installed, - the directory pointed by the HyperDocCfg environment variable, - the directory pointed by the HyperDocCfg key in the General section in the HDoc.Ini file.
If HDocCfg.DAT file is not found, then HyperDoc works in old native database accounts mode. Otherwise HyperDoc works in new proprietary user list mode: it connects to database using common login name and password read from the HDocCfg.DAT file. You can control HyperDoc login mode with HyperDoc Administrator utility.
HyperDoc uses security settings from the system database file (System.mda). The location of this file is set by the SystemDB parameter of the [Options] section of the HDoc.ini file. One can use MS Access to modify the System.mda settings. To make MS Access use this particular System.mda use the Workgroup Administrator.
The setup program installs the default System.mda file with the following users:
User: Admin, password: admin User: User1, PID: 0000, no password User: User2, PID: 0000, no password
Because all HyperDoc users must belong to the Users group, we suggest not assigning this group the right to read HDocUsersRights table, because this would make all HyperDoc users HyperDoc administrators, which is rarely an intended security policy.
Each user can have its own login and password. Each user’s login must have HyperDoc database set as the default database. Users’ logins must be given the SELECT permission (i.e. the right to read) in the HDocConfiguration table from HyperDoc database. If the HyperDoc system account name has been changed, administrator must use SQL Server Enterprise Manager to make sure that the default database of the system account login is HyperDoc database and that this login has all necessary rights to all HyperDoc tables. Because all HyperDoc users must belong to the public group, we suggest not assigning this group the right to read HDocUsersRights table, because this would make all HyperDoc users HyperDoc administrators, which is rarely an intended security policy.
HyperDoc security uses user and group definitions of the underlying DBMS system. It works on two levels: user-level security and document-level security. User-level security defines user or group rights for protected operations for all documents.
Document-level security uses concept of security classes. Each document has a certain security class. Each security class has an access control list defining user and group rights for all documents of this security class. Rights are defined in terms of protected operations (which are almost the same as in user-level security).
User-level rights are a logical sum of rights defined for the user and all groups to which this user belongs. To see the actual user-level rights check the Show Effective Rights box in the User Permissions dialog.
For a user to be able to perform certain protected operation on a given document he/she must have both user-level right for this operation and document-level right for this operation to the document’s security class. When the document has no security class assigned only user-level rights apply to this document. To see the actual document-level rights check the Show Effective Rights box in the Security Class Permissions dialog.
Access rights apply to a document as a whole; there are no specific rights for versions of the document.
The access rights defined in HyperDoc are as follows.
Right | Description |
Access documents | Access documents |
Modify documents | Modify documents |
Delete documents | Delete documents |
Add versions | Create new version of the document |
Modify versions | Modify existing version of the document |
Delete versions | Delete version of the document |
Import versions | Import version of the document |
Export versions | Export version of the document |
Modify links | Modify links from spots |
Modify document attributes | Modify attributes of the logical document |
Modify object attributes | Modify attributes of business object |
Access contents | View contents of the document |
Modify contents | Change contents of the document |
View external file formats in HIS | Allows working with external documents via HyperDoc Online |
View system | View spots on system layers |
Modify system | Modify spots on system layers |
View foreign | View spots on other users’ layers |
Modify foreign | Modify spots on other users’ layers |
Enable modification** | Create or modify any spots |
View system | View redlining on system layers |
Modify system | Modify redlining on system layers |
View foreign | View redlining on other users’ layers |
Modify foreign | Modify redlining on other users’ layers |
** - When a user does not have this right, he cannot create, modify or delete any spots. He cannot switch between Object Overlay and Redlining drawings. He can select vector entities on them both without switching between them. Any vector object he creates is created on the Redlining drawing.
We have implemented type of security classes that can be applied to designated document types.
By using this feature you can control user rights to see and perform various actions against type of documents, no matter where they are located in Database.
Configuration
Activation of this functionality requires database modification:
Open HyperDoc Configuration Manager (
HDCfgMan.exe) with INI pointing to chosen database,Log in as administrator,
Select menu
File/Check and Create Extra Tables.
Using security class
New menu option has been added to Tools menu in HyperDoc - Security Classes for Types.
This option opens Choose Type to Assign a Security Class dialog where you choose document type for which the security class will be created.
Security class dialog of chosen document type dialog will appear.
Note
If the dialog shows up with one of the security classes selected (on blue) this means that this security class refers to selected document type. So do not create new security class but modify the existing one.
Click New Class to create new security class for chosen document type.
Tip
It's recommended to name the security class using name of the document type chosen as it will be easier to recognize them in the future
By default permissions for new security class are blank so click Permissions...button to customize them.
Future managing the security classes for documents types is same as for normal security classes.
Described here is a simple scenario where we want to apply security for three groups of users:
Architects, that can access “Object 1”
with it's sub tree and only documents of “DocType 1” 
Engineers, that can access “Object 2”
with it' sub tree and only documents of “DocType 2” 
Administrators, that can access all objects
+
and all documents +
For easier management it is recommended to use separate Security Classes for document types. You can use one SC per type, or for several types that need the same security settings.
Setup user accounts
create group Administrators, Architects and Engineers. Grant appropriate rights to each group,
add users as needed,
users and groups can be defined using HyperDoc Administrator,
user and group rights can be assigned using HyperDoc Tools\User Permissions.
Setup Security Classes using HyperDoc Tools\Security Classes dialog. Use New Class to create “Security Level A”. It will be used to secure objects of “
blue” categoryedit this class and select user rights for groups (Permissions...),
for Architects and Administrators check appropriate rights and verify by selecting “View Effective rights”,
for Engineers un-check appropriate rights and verify by selecting “View Effective rights”,
assign this class to blue category objects by rights click on object and using “Change Security Class…” option.
Repeat steps for “Security Level B” that will be used to secure objects of “purple” category
.To apply security class to all objects and documents (sub tree) use Security Class Clone add-in for HyperDoc.
After completing above steps you have secured access to objects and connected documents. Next problem is the fact that Architects and Engineers will have access to all types of documents. To limit this access to specific types, follow instructions in next steps:
“DocType1_SC” will be used to define access to DocType1
Create new class and give it a meaningful name. You can create one security class per document type, or group them in logical entities. If you want to apply the same access rights for several types, the same security class can be applied. Here we will create per type security and therefore create class called: “DocType1_SC”,
Edit this class and remove all rights for Engineers group (leave unchecked) and add rights to Architects and Administrators,
Assign this class to DocType1 by using HyperDoc Tools\Security Classes for Types,
Now this document type will not be available for Engineers.
Repeat this steps for “DocType2_SC” that will be used to define access to DocType2
HyperDoc has been extended with possibility of using proprietary groups with already implemented Proprietary User List mode.
Important
If user is added as a group member his effective rights are the sum of his personal rights and rights resulting for all his group's memberships. Please note that groups cannot be set as group members in this mode.
MSSQL users and groups can be also managed using HyperDoc Admin tool and HIS sites described above. But in this case, there are some limitations.
java Here are some of them: fixed database roles couldn't be deleted, public role and dbo user shouldn't be managed using above tools. User used by HyperDoc Internet Server needs to have enough rights for users and groups handling (please refer to Microsoft MSDN to check rights requirements).
To enable using of proprietary groups with proprietary users one has to use “Check and Create Extra Tables” option from HyperDoc Configuration Manager's File menu.
Then they would be available after setting Proprietary User List mode in HyperDoc Admin from User list mode menu.
Proprietary groups and users memberships can be managed from within HyperDoc Admin tool or using hisUsers.asp and newly added hisGroups.asp web pages.
hisUsers.asp has been extended with Groups button.
List of operations possible to be done on hisUsers.asp site:
adding new users,
changing users passwords,
deleting users,
setting users memberships,
setting users permissions (HyperDoc rights).
The page looks like this:
HyperDoc accesses document files through the file system facilities of the underlying operating system. The documents can be stored on local hard disk or on a file server in a LAN environment. contains more detailed information on how HyperDoc uses logical devices concept. Each HyperDoc user should have read/write access to his default logical devices (import device, spots device and redlining device). HyperDoc administrator can set users’ access rights to other logical devices according to local policy. The user will be able to view document contents when given read access to the logical device on which the document contents is stored. Similarly the user will be able to modify document spots and/or redlining when given read/write access to the relevant logical devices.
