X500Standard.com

The X.525 part of the X.500 series specifies protocols and procedures for replicating directory information. Replication is the act of copying information from one DSA to another DSA.

There is also a whitepaper on X.500 replication, which presents information supplementary to this page.

X.525 recognises two modes of replication:

• Caching, where a DSA retains information retrieved from another DSA when performing an operation for one user. I may then use this information for subsequent use when serving other operations. This is a somewhat hazardous mode of replication, as information retrieved for a privileged user may later be used to serve less privileged users. In addition, the information may be out of date, as there is no consistent updating. A user may indicate in a request that cached information shall not be used to satisfy the request.
• Shadowing is the standard way of replication, and it is the primary scope of X.525 and of this page. Shadowing requires protection specifications to be shadowed together with the information it is designated to protect thus allowing the receiving DSA to perform proper protection.

There are several good reasons for shadowing data:

• data can be brought closer to the user and in this way improve performance;
• multiple copies of information can provide load sharing;
• multiple copies improve availability in case of a single DSA failure; and
• data protection can be improved by shadowing less sensitive information to a DSA accessible by many users and leave sensitive information within a secured environment.

One of the copies is the master copy. All maintenance of data is done toward the DSA holding this master copy. The other copies, also called shadows, can only be used for retrieving data (read-only).

Figure 1 shows a simplified shadowing model. DSA-A holds the master data. This data is shadowed to both DSA-B and DSA-C. In this configuration, DSA-A is called the shadow supplier, while DSA-B and DSA-C are shadow consumers. A shadow consumer may in turn copy the received data on to one or more other DSAs. This is also illustrated in Figure 1. DSA-C acts a shadow consumer toward DSA-A and as shadow supplier toward DSA-D for (part of) the same data. This is called secondary shadowing, while the shadowing from the master to a consumer is called primary shadowing.

Figure 2 gives more details on the shadowing process. Not all data held by a shadow supplier needs to be shadowed to a consumer. The shadowed information constitutes one or more units of replication. A unit of replication is in principle a subtree within the supplier DSA as indicated in the left side of figure 2. However, not all the information within the indicated subtree may necessarily be shadowed. Some selected entries may be excluded. Likewise, some attributes in some of the entries being copied may also be excluded. The absence of some entries in the unit of replication is illustrated in the right side of figure 2.

Figure 2 also illustrates that a consumer may also hold master information of its own.

The terms supplier and consumer only apply to a particular unit of replication. A DSA may be supplier for one or more units of replication and at the same time being consumer for other units of replication.

A shadowing agreement has to be established between the supplier and the consumer before transferring shadowing information. Such an agreement is primarily established using off-line procedures. An agreement consists of such things as:

• An integer that identifies the agreement together with a version indicator (which is also an integer).
• The unit of replication to be shadowed.
• How the update is being performed:
  • Push mode, where the supplier takes the initiative to update the shadow either at fixed intervals or when changes have occurred.
  • Pull mode, where the consumer initiates the update.
• Actions to be taken when the shadowing agreement is terminated, for example that the consumer shall delete all the shadowed information.
• Whether the shadowing agreement shall be activated implicitly or explicitly.
• Etc.

A directory implementation needs to be initialised with some of the shadowing agreement parameters, such as the unit of replication, update mode, etc. This may happen in one of two ways:

• implicitly, that is, the initialisation or customisation is done off-line on both the supplier DSA and the consumer DSA; or
• explicitly by use of protocol exchange as explained below.

Shadowing is supported by several X.500 Vendors. Implementations will typically not support all possible aspects of shadowing. A shadowing agreement therefore has to reflect the intersection of the feature supported by the two involved DSA implementations.

When a shadowing agreement is explicitly activated, an activation protocol exchange is required as illustrated in figure 3. It may also be seen as a confirmation of the agreement previously established. It provides a higher level of assurance that the two partners have a common view of the shadowing agreement. A special protocol called Directory Operational Binding Management Protocol (DOP) is used for this protocol exchange. As indicated in figure 3, either side may initiate such an exchange. The request contains such information as:

• agreement id;
• which role to be taken by whom, that is who is the supplier and who is the consumer;
• who initiates updates; and
• the unit of replication, which is an ASN.1 construct that specifies the details for what is to be shadowed.

When a shadowing agreement has been activated, either implicitly or explicitly, updates may be performed using the Directory Information Shadowing Protocol (DISP).

Figure 4 illustrates the push mode, where the shadow supplier takes the initiative to the update. The transfer is notified by a coordinateShadowUpdate request. This request contains the following information:

• The agreement id.
• The time of the previous update. This parameter may be absent if there has been no previous update (or in case of some specific conditions).
• Whether a complete update or an incremental update will be done. In the latter case, only changes to the replication unit will be transferred. However, no changes may have occurred since the previous update and there is no information to transfer.

If the parameters are acceptable, a result is returned. The result depends on whether it is to be signed or not. If no signing, it is just a simple confirmation (returning the ASN.1 UNIVERSAL type NULL). If signing is to be done, some information is included in the result. In addition to what is shown in figure 4, some security parameters are also included.

If the parameters of the coordinateShadowUpdate request are not acceptable, it is rejected by an Error instead of a result (not shown in figure 4). There can be several reasons for this rejection, such as an invalid agreement id, an inactive shadowing agreement, etc.

If the supplier receives a coordinateShadowUpdate result, it will then transfer the actual shadow update in an updateShadow request. The updateInfo within that request is a rather complex ASN.1 construct that contains the update information (or an indication that there is no information to transmit). In addition, the agreement id and the update time is transferred. There may also be other parameters not shown in figure 4. The supplier may indicate a time interval for the next update, and if the updateShadow request is to be signed, it must also include some security parameters.

If the parameters of the updateShadow request are acceptable, a result is returned similar to the one for the coordinateShadowUpdate.

Figure 5 illustrates the pull mode, where the shadow consumer takes the initiative to the update. The transfer is requested by a requestShadowUpdate request. This request contains the following information:

• The agreement id.
• The time of the previous update. This parameter may be absent if there has been no previous update (or in case of some specific conditions).
• Whether a complete update or an incremental update is requested.

A requestShadowUpdate may be rejected in much the same way as the coordinateShadowUpdate.

If the supplier sends a requestShadowUpdate result, it will then transfer the actual shadow update in an updateShadow request as discussed above.