X.500 Standard status
(Implementors' Guide)

X.509 Related activities

How to be involved

More Information

Tutorial section 1
X.500 General

Tutorial section 2
X.509 specific

Other PKI organizations

edit SideBar


X.500 Service Administration

This page gives more details on how the service-oriented view has been incorporated into the X.500 Directory Specifications.

Service specific administrative area
Figure 1 - Service specific administrative area

An administrative authority may provide a particular service from a confined area of the directory. This area may be all of an autonomous administrative area. A new administrative role for service administration has been defined. The autonomous administrative area is then serving as a service specific administration area. An autonomous administrative area may be subdivided into several service specific administrative areas as for other types of administrative areas. It cannot be further divided into inner administrative areas.

The service is controlled by search-rules. The specifications of search-rules are established within a new type of subentry to be positioned as immediate subordinates to the service specific administrative point.

A search that starts within a service specific administrative area is confined to that area, unless explicitly specified otherwise. A search starting outside a service specific administrative area will not be allowed to spread into that area. Extensions are under development that will allow a search in a controlled manner to be spread to other areas.

Service subentries

Search-rules are stored in service subentries for the service specific administrative area within which they apply. Within such a subentry one or more search-rules can be stored in an operational attribute. An administrator can elect to create a subentry for each search-rule or can elect to include several search-rules in a subentry.

On the Service-oriented view page the somewhat fuzzy concept of user groups is defined. The user group concept is closely related to access control. Operational attributes with search-rules are assumed to be protected by access control using the invoke permission category. A user can invoke a search-rule if it has invoke access right to that search-rule.


A search-rule:

  • Polices for what searches can be performed by certain user classes
  • Polices that right search criteria are being used
  • Adjusts the search request to increase the chance of success
  • Determines what information to be returned

A search within a service specific administrative area is policed by a governing-search-rule. For a search to proceed, it has to comply with at least one search-rule defined for that area. One of the search-rules with which the search complies is selected as the governing-search-rule. If there is no suitable search-rule, the search is rejected.

Search-rules have some similarities with access controls. While access controls restrict access rights to entry information, the search-rules restrict the rights to perform searches.

Search-rule overview


Subset and size limited


Entry information selection

Operations controls

Families of entires

Search relaxation

Figure 2 - Search-rule overview

The "seven-layer" model illustrated above shows what groupings of components go into a search rule. These groupings are discussed in the following subsections.

Search-rule identification

A search-rule is globally uniquely identified by:

  • an integer, than uniquely identifies a search-rule within a Directory Management Domain (DMD); and
  • an object identifier that globally uniquely identifies a DMD.

A search-rule also specifies as part of its identity:

  • what service-type it supports; and
  • what user-class it is primarily intended for.

Subset and size limit constrains

A search request includes either implicitly or explicitly the scope of the search in form of the subset parameter, i.e. whether the scope is baseObject, oneLevel or wholeSubtree.

The search-rule may have a subset specification that overrides whatever the user specifies in the request, unless the user prohibited that by a search control. The purpose of this parameter is to ensure that a search based on this search-rule returns the optimal result. If this specification is not present or has been prohibited by search control, the search request subset parameter is checked against another specification that lists all valid choices for the subset parameter. If the search request then violates this specification, it does not comply with the search rule.

The standard service control in a search request can specify a size limit, i.e. the maximum number of entries to be returned. If present, this size limit is checked against the governing-search-rule if or when such a search-rule is identified. If exceeding the governing-search-rule maximum specification, the size limit is reduced to that maximum. If no size limit is specified in the request, a default size limit is applied not necessarily being the same as the maximum size limit.


A service-type specification, e.g. by F.510, lists the attribute types relevant for the service-type. Some of the attribute types shall be present in the filter, other attribute types may be present in the filter, and some attribute types have to be present under certain conditions or in certain combinations. Other attribute types (omitted attribute types) shall not be present in the filter. If entries hold attributes that are not part of the service, such attributes are not allowed in the filter and will not be returned in the result.

A search-rule includes a request-attribute-profile for each attribute that shall or may be represented in the filter. If a search filter specifies an attribute type not represented by any request-attribute-profile within the search-rule, the search does not comply with the search rule.

For an attribute type to be effectively present in the filter, at least one filter item for that attribute type shall conform to the request-attribute-profile for the attribute type.

Attribute type

Selected values

Default values

Contexts specifications

Matching use

Figure 3 - Request-attribute-profile

The table above illustrates the overall structure of a request-attribute-profile. The individual components are described in the following:

Attribute type

The attribute type component indicates the attribute type for which the profile applies. A search-rule can only have one profile for a given attribute type.

All the other components of a request-attribute-profile relate to this particular attribute type.

Selected values

For some attribute types it is only relevant to specify certain values in the filter. The selected values component, if present, specifies a set of such attribute values. If a filter item for that attribute type specifies a value that matches (e.g. by substring match) one of the values specified in the profile, this attribute type is effectively present as far as this component is concerned.

Default values

The default values component specifies a set of attribute values. If an attribute of the type is not present in an entry being matched, it is assumed for the purpose of matching that it holds an attribute of this type and with values specified in this component.

Context specifications

As contexts can be part of a filter item, it is possible to specify requirement on context specifications. For a given attribute type it is possible to specify whether contexts may used, and if so, what context types and possibly what context values may be used. Also restrictions on context combinations may be specified.

Matching use

In the matching use the administrator may specify what matching rules may be used for the attribute type. It may also specify restrictions on how a given, possible complex matching rule may be used.

Request-attribute combinations

Certain attribute types shall be present in the search filter, others may be present, and again others have to be there in some combination, for example that at least one of two attribute types has to be present. Such conditions are expressed by a filter like expression with AND, OR and NOT operators. Entry information selection

Entry information selection
Figure 4 - Entry information selection

Traditionally, the information returned in a search result is determined from the entry information selection specification in the search request. As default, all user attributes with all values are returned (subject to access control). Search-rules changes that somewhat by specifying that all attributes and contexts as specified in a listed in the governing search-rule are returned (still subject to access control). An administrator can then for the same service-type define different search-rules for with different sets of attributes to be returned. It is still possible for the user specify entry information selection to reduce what is returned if a search is expected to return many entries. If that is done, only the intersection of what the search request specifies and the governing-search-rule specifies is returned as illustrated above.

Operations control

A search operation is affected by service control options, controls directly in the search argument (search control options) and by hierarchy selection specifications. All these controls are supplied as bits strings in the request.

A search-rule can specify defaults for some control, it can override some controls, and it can require that the user sets some controls in a particular way for the search to comply with the search-rule.

Families of entries

The governing-search-rule can override the family grouping specification in the search request.

A governing-search-rule can also as part of its entry information selection specifications specifies changes to the marking of entries as it was done during matching and it can override the family return specification in the search request.

Search relaxation

A governing-search-rule can specify details about mapping-based searches and search relaxations shall be performed.

Page Actions

Recent Changes

Group & Page

Back Links