Previous section.

Technical Study: Security in Federated Naming

Technical Study: Security in Federated Naming
Copyright © 1997 The Open Group

Federated Naming Specification (XFN)

This chapter provides an overview of the XFN specification for those readers unfamiliar with the specification to place the discussion on security into context. Where possible text and figures have been drawn from the XFN specification itself to avoid errors in interpretation.

Naming Services

Naming services are a fundamental facility within all IT systems providing the means by which names are associated with objects, and by which objects are found given their names. A naming service provides operations for:

Traditional systems include a multitude of naming services, usually integrated with another service, such as a file system, directory service, database, desktop, mail system, spreadsheet, or calendar.

Each of the naming service interfaces differ widely and the essential naming operations are often obscured.

Furthermore, within a distributed system, the name of an object may be composed of elements from several different naming systems. Such a name is referred to as a composite name.

Federated Naming Specification

A federated naming system is an aggregation of autonomous naming systems that cooperate to offer a standard interface for the resolution of composite names and supports the addition of further types of naming services without requiring changes to applications or to existing member naming systems.

The Federated Naming Specification (XFN) defines an interface comprising a set of common naming operations, that map a composite name to an object reference. The XFN does not specify administrative interfaces as the administrative models of different naming services vary too widely to permit a useful generic treatment.

The XFN is intended to be implemented over a number of existing naming services, using their existing programming interfaces and protocols, as well as with new naming services in the future.

The components of the XFN specification are:

There are additionally optional components:

Implementation Models

The XFN specification does not prescribe any method of implementing the XFN service but does present the following guidelines reproduced from the XFN specification to provide a basis on which to consider the security aspects of XFN.

The three diagrams XFN Configuration using Client Context Implementations , Lightweight XFN Client Configuration and XFN Configuration with Surrogate Client serve as examples of the conceptual models of the different possible configurations. The dark shaded boxes shown in these diagrams are building blocks that a naming service integrator needs to provide in order to integrate the naming system with XFN. The modules depicted in the three diagrams are defined as follows:


The XFNAPI is the complete set of interface operations defined in this XFN specification.

XFN Framework

The XFN framework is the implementation of the XFN API, including the client library and the service provider interfaces necessary for integrating native naming systems.

Context Implementation

The context implementation is the naming service-specific module on the XFN client system that is required to integrate legacy naming systems with XFN. The code of the context implementation is a wrapper that maps the XFN API to the API exported by the legacy naming system. The complexity of the context implementation depends on how well the XFN API maps to the native naming service API and which XFN operations are to be supported. At a minimum, the name resolution phase of all operations must be supported.

The techniques used to access the naming service-specific context implementations from the XFN framework may vary. For systems that support shared libraries and dynamic linking, a common approach might be that the context implementations are dynamically loadable modules.

This approach of integrating a naming service using a context implementation module does not require any modification to the existing naming service's source code nor does it require access to the naming service's source code. All that is needed is access to the module (library) that exports the naming service-specific API. This approach is by far the easiest and fastest way of adding an existing naming system into the XFN federation.

XFN Client

The XFN client is a module that implements the client protocol machines for the XFN protocols.

Two XFN protocols are specified, the RPC based protocols for ONC+ systems (specified in RPCL) and for DCE environments (specified in IDL).

In addition to supporting the protocols, the XFN client might provide services typically offered by naming clients, such as caching. The extent of this support is implementation-specific.

XFN Protocol Exporter

The XFN protocol exporter is the module required on systems that export one of the XFN protocols. This could be a new naming system, an existing naming system that was modified to also support XFN protocols, or a system that supports the XFN client library and also exports XFN protocols (capable of acting as surrogate client).

The advantage for naming systems that support one of the specified protocols is that any existing XFN client that imports the protocols can be used to communicate with it. This is particularly useful for applications that need to export naming interfaces. Application programmers do not have to duplicate the client-side implementation and they do not have to invent new naming interfaces. This provides additional benefits such as the ability to utilise caching and other mechanisms provided by the XFN client implementations, and a direct (and possibly more efficient) mapping of XFN operations to the application's naming operations.

XFN Configuration using Client Context Implementations shows the layering of the XFN client library on top of existing naming system clients on the same system. None of the legacy naming systems needs to be modified.

Figure: XFN Configuration using Client Context Implementations

Lightweight XFN Client Configuration shows multiple XFN systems that are connected via one of the specified XFN protocols. The client in this picture is a lightweight XFN client. The servers shown are name servers that directly export one of the specified XFN protocols.

Figure: Lightweight XFN Client Configuration

The two modules shown in XFN Configuration with Surrogate Client are a lightweight XFN client and a server that acts as an intermediary. Similar to the client in Lightweight XFN Client Configuration , the client in XFN Configuration with Surrogate Client is a truly lightweight XFN client. None of the legacy naming system clients needs to be installed at that system. Depending on the client system's requirements, the XFN client can be implemented and configured to consume more or less resources, determined based on needs and availability. The XFN client might simply defer to mechanisms (such as for caching and replication) provided by the native naming system clients.

The legacy naming system clients in XFN Configuration with Surrogate Client reside on a remote system (similar to XFN Configuration using Client Context Implementations ) that also exports at least one of the XFN protocols. This remote client can be viewed as a surrogate or proxy client that acts on behalf of the initial requestor and performs the native naming system functions.

Figure: XFN Configuration with Surrogate Client

Another aspect shown in XFN Configuration using Client Context Implementations and XFN Configuration with Surrogate Client is the capability of the surrogate client to also import the XFN protocol (XFN client module). Such a configuration could serve emerging XFN servers or existing name servers that export one of the specified XFN protocols in addition to, or in replacement of, the native protocol.

Note that a context implementation precisely defines the set of modules that are co-located with the XFN framework to map the XFN API to the native naming service API. However, in the context of this description, we also use the term context implementation to mean the XFN mapping code that is necessary at the server of a naming system that directly exports one of the XFN protocols ( XFN Protocol Exporter and XFN Server in the diagrams).


The XFN client interface comprises the following categories of interfaces:

A summary of the XFN functions is presented below with the functions grouped in a categorisation with a security perspective in mind. That is functions are grouped with the definition of security policy in mind. The names of the functions listed provide a good indication of their purpose and the style of the interface. The reader should refer to XFN itself for more detail.

All name resolution operations occur by reference to a context. A handle to an XFN context is an input parameter to almost every XFN function. Before the XFN functions may be used an initial XFN context handle must be obtained. Handles to additional contexts represented by an XFN reference are obtained from a name lookup operation. The functions that manipulate XFN contexts are:

The principal purpose of a name service is to resolve names to object addresses, or XFN reference. The functions that support this purpose are:

To support the name resolution process name to object bindings must be created and managed. the set of functions that support this functionality are:

The creation of a subcontext creates a new branch in a context namespace. (It is like a mkdir operation in a filesystem.)

The attribute related functions included under bind management are part of the extended attribute interface and provide for the creation of objects with attributes assigned as part of the creation operation.

A secondary purpose of a name service is to support the assignment of information attributes to objects and the sharing of that information between users of the name service. The XFN includes functions that operate with single attribute values, multiple attribute values, and multiple attributes:

The extended attribute interface provides for search capability based on attributes. The functions are:

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index