Security of the Object Space

The integrated object space may be used for solving critical tasks only if it gives flexible and reliable technology for ensuring object access security. First of all, it requires permission management for reading, referring and modifying objects.

There are three levels of permission management: object space, intersystem and network. The object space's security management enables for authorized people to do certain activity over some objects. When necessary, permissions can be logically propagated down the object tree to simplify administration. It lets us describe the most general permissions once on higher levels of the object tree (as a rule, permissions of reading and referring to public objects), and special permissions on lower levels for nested objects.

Before permissions can be verified, a service should know the user, on behalf of which some activity is being carried out. For that, the user should connect to the object space and go through the process of authentication. But where to store user information, taking into account that storing user names and passwords at one place is not convenient, scalable, or reliable solution? In this case, by increasing the quantity of users, their names will tend to be duplicated. Moreover, access to user information will be done though a single node. Loosing connection with this node will result in unavailability of the object space for all users in the whole. So, the solution with a single node is not appropriate at all.

In our solution, users of the global object space are described as objects of the special type, and the objects can be stored at any part of the space. Of course, the solution does no exclude usage of one or several services for centralized user management. But at the same time, any company, which decides to manage user accounts by any reason, can do that within its own services. One of motives of such decision may be ensuring accessibility of the object space for some users, for instance, for employees of the company.

It is evident that user passwords should be encrypted by means of one of known digest algorithms proved their effectiveness. In our solution, for instance, a user can choose the algorithm in case he (she) wants to choose.

To simplify administration, the object space should let group users into roles: groups of users solving similar tasks. It allows permission management on the level of roles, not separate users, which increases flexibility of the administration process. So, for an administrator to give some standard permission set to a user, it is sufficient to give the role having the permissions.

The second level of permission management is the systems, having services operating over them, themselves. The systems may have their own mechanisms of authentication and authorization, as a rule, in case of DBMS usage. The object space should give the possibility to use the mechanisms as another security layer.

At this level, a name and a password to access a certain external system may be assigned for a role or a user. To make administration simpler, the assignment can be done automatically with a special tool. Then an administrator can manage permissions for the role/user using system-dependent tools on the level of the system itself, for instance, DBMS. If a permission set should be given to any user connected to a certain external system, then a guest account should be provided for the system, which is to be used for unregistered users.

And the last level of security is the network level. Let some company consider necessary to create a system as a part of the integrated object space, so that it can refer and use external objects published globally, but intersystem objects are to be accessible within local network (or VPN) only, for example, because of financial character of the system. In this case, access to the local service can be restricted not only on the level of the object space or DBMS, but also on the network level by forbidding any external connections to the object space service. As a result, the local service will be operating as a part of the global object space, but it will not be accessible from the outside.