| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

Authorization

Most authorization is implemented in practice using Access Control Lists (ACLs). But Access Control Lists can differ quite markedly in their levels of sophistication—from exceptionally weak to pretty near foolproof.

We saw in the section on policy that the security administrator sets policy by stating:

  • the users allowed to access the system
  • the applications and data they can access and the types of access allowed
  • the equipment and other hardware they can use to gain access
  • the times of the day, week, and so on they are allowed access
  • and the locations to which and from which they are allowed access

Ideally, and at its best, the Access Control List should be able to record every one of the criteria and rules stated in the policy, and the Access Control service should moreover be able to check all these things too. Authentication establishes the identity of the user and is the key entry point to an Access Control List. Each user will have a whole list of allowed accesses he or she is allowed to perform.

When a user requests a service, for example, the Authentication service will first check the identity of the user. Once this has been established, the Access Control Service should take over using the authenticated identity as the key (more than one key may be permissible here to cater for multiple identities). Access Control services should not only check that the user is allowed to request the service but should check that the user is accessing the service from the right location, from the designated machine, is accessing the service on the machine he or she is allowed to, and at the times of the day he or she is allowed access.

It has to be said that most middleware products—most security products for that matter—fall very far short of this ideal. Some are very poor and only check the service itself—no times of day, no machine restrictions—nothing else at all. Some are a little better with times and machines allowed, but overall, don’t expect too much from any of the products—something I feel needs to be urgently addressed.

Access Control Lists must be secure files subject to Access Control (it must be a secure file as there is no point in having it). The contents of the file are set up manually by the administrator using the security policy document. This file can be a:

  • Globally relevant file containing all the policy rules for all users—this file may occur just once on the network but be accessible to all in the network, or a better option for performance reasons is an automatically (but secure) replicated file which is stored on each machine.
  • File which just has the policy rules of the users connected to that server machine.

As we saw with the user/password approach, the first option, especially if it uses replication, is probably the best solution, as it saves the administrator effort and is more easy to keep secure.

One further means of implementing authorization rules is to issue the policy rules with Digital Certificates. Policies recorded in this way are called Digital Certificate Privileges. Clearly, for this to work well, the policy rules must be exceptionally stable, and the user themselves should not be able to gain access to the rules. I feel that this is actually a less satisfactory solution altogether, requiring far more administrative work and liable to error. I won’t therefore be covering it further.

Encryption

We saw that there were essentially two methods of encryption—public and secret key.

Public-Public key encryption is based on the Digital Certificates we saw in the previous section. Where a message from one process to another is to be encrypted, however, the sender uses the public key of the recipient to encrypt the message. By doing this only the recipient is able to decrypt the message as only the recipient has the private key. The sender first gets the public key of the recipient from the Directory of public keys. The public key is then used by the sender to encrypt the message. It is then sent and decrypted by the recipient using its private key.

But how can the person sending the message be sure that the public key they are about to use is really that of the recipient? If they use the wrong key—are fooled into thinking another key is the public key—they could encrypt the message and it is then diverted by the interloper and decrypted with his private key.

The key is in the way the Directory sends the public key to the sender. The sender applies to the Trusted Third Party/Digital Certificate Authority and requests the public key of the recipient, using some identifier of the recipient. The Digital Certificate Authority encrypts the public key with its own private key. The sender has a permanent record of the public key of the Digital Certificate Authority and can then decrypt the message and extract the public key of the recipient.

What does this actually achieve? By doing this, the message could only have come from the Digital Certificate Authority, as only the Digital Certificate Authority has the private key to encrypt the message, so the sender can be confident that an interloper has not butted into the conversation and substituted some other public key for the recipient’s. In essence, the sender can be confident that only the intended recipient can read the message.

These messages containing the public key of some process encrypted using the DCA’s private key are known as “Public Key Certificates.” Public key encryption is an especially useful form of encryption method because it can be used over the Internet as long as the Directory of public keys is accessible to the sender. It means that any user, wherever they are located, can encrypt a message before it is sent across the line without having to prestore any encryption routines on the machine he or she is using.

Previous | Table of Contents | Next