Previous section.

Technical Study: Security in Federated Naming

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

Implications of Security on XFN

Mapping of XFN to XDSF Concepts

A basic concept of the Distributed Security Framework (XDSF) is to view an IT system as comprised of a set of interacting and in some cases interdependent security domains. A security domain is defined as " A set of elements, a security policy, a security authority and a set of security-relevant operations in which the set of elements are subject to the security policy, administered by the security authority, for the specified activities". At this level each service (or application) can be viewed as an individual security domain enforcing its own security policy over the application entities within the domain. Each service or application services principals, that is users or other services, that are external to the service or application.

Services are provided by the exchange of information across the domain boundary. The service can only identify the principal via information exchanged between the principal and the service. In order to prevent the masquerade of one principal by another the identification information supplied requires authenticating.

The service may exercise access control on the basis of the authenticated identity, or it may associate other security attributes with the identity for the purposes of mediating authorisation to access entities or exercise activities of the service. For example security attributes may include group affiliation, authorities or privileges, role, etc.

Security Domains in XFN Operation illustrates the security domains involved in the implementation of XFN. Each name service that is integrated as part of XFN comprises a security domain in its own right. The entities within the domain are the bindings and object attributes maintained by the name service for the namspace that it services. Each name service enforces a security policy over the operations it provides to access and maintain those bindings and attributes in that namespace.

Figure: Security Domains in XFN Operation

The application client invoking the XFN API executes within a security domain representing an end user principal or a system service principal. Associated with the application client is a security context that includes the authenticated identity of the principal and any security attributes associated with the principal within that domain.

In invoking the services of a name server the XFN implementation must propagate the appropriate parts of the security context, normally at least the principal identity, to the underlying name service. The name service will require to verify the authenticity of the information it is passed.

In the context of the XDSF, the distributed security services provide an authentication service and security attribute service that are trusted by both the user sign-on service and the name service. The name service will verify the authenticity of the security context information it is passed by verifying that it is originated by or certified by the security services it trusts.

Relevant Threats

Of the threats identified in the previous chapter the following are not directly relevant to, or cannot be addressed at the level of the XFN API Specification:

Even though these threats are not directly relevant to the XFN specification itself they are of relevance to name service implementations and could be included in any guidance to implementors.

The threats that are directly relevant in the context of the XFN API itself are:

Current Security Provisions within XFN API

The XFN API includes the following statements regarding security:

XFN does not define a security model nor a common security interface for contexts. Security-related operations, such as those required for authentication or access control, fall into the category of administrative interfaces which are expected to differ widely amongst federation members. Any single choice of security model at the XFN layer is prone to be fundamentally incompatible with the security provided by other direct interfaces, thereby giving rise to inconsistent protection that is susceptible to compromise. Consequently, the security administration interface is kept entirely separate from the federated naming service interface, outside the scope of XFN.

The XFN does, however, provide means by which security can be integrated with specific XFN implementations. Operations that fail due to security-related problems can indicate in the status code the nature of the failure.


Authentication is handled in the modules that implement the service interfaces for each particular member naming system. It occurs as part of the communication that occurs between the client and the naming service. Significant engineering issues remain when multiple security mechanisms and administrative domains are involved. These problems can be addressed on a one-to-one basis, or via a general federated security model, outside the scope of XFN. XFN provides the status code [FN_E_AUTHENTICATION_FAILURE] to indicate that an operation failed due to authentication errors.

Access Control

Given the ability to authenticate the principal making a service request, a context service provider must then decide whether this principal should be granted or denied the request. Access control is to be handled through additional interfaces in the specific contexts. This can be done by having operations that control default authorisation at context creation and binding creation times, and having interfaces that modify the current authorisation settings. This is analogous to the umask and chmod scheme for POSIX.1 files.

The access control model is outside the scope of XFN.

XFN provides the status codes [FN_E_CTX_NO_PERMISSION] and [FN_E_ATTR_NO_PERMISSION] to indicate that an operation failed due to access control errors. In the case that the principal is not authorised to know that access has been denied due to permission problems, the status code [FN_E_NAME_NOT_FOUND] or [FN_E_NO_SUCH_ATTRIBUTE] is returned.

As indicated in the previous chapter, this Study generally concurs with the above approach. A name service may support anonymous client principals, or exercise access control at the levels of an enterprise, organisational unit, or individual. It is necessary for an implementation of the XFN or underlying name services to be able to retrieve and propagate any necessary authentication and security attribute information to support the particular access control policies enforced by a name service but it is not necessary to supply or manipulate such information via the XFN API. See Potential Impact on XFN API for an expansion of the potential impact of security on the XFN API.

It should be noted in the guidelines on implementation that there is an implicit assumption that the context implementations are able to retrieve appropriate authentication credentials from the processing environment of the client application. This may be via operating system process attributes or retrieval from a suitably protected credential cache perhaps combined with the invocation of appropriate distributed security services.

Any further discussion on this point would result in a general dissertion on distributed system security services for which the reader is referred to the XDSF.

The XFN specification includes the following measures to address the non-availability of services:

Potential Impact on XFN API

The services offered by XFN API may be categorised as:

Potential Impact on XFN Protocol

XFN defines two XFN export protocols, one based on DCE and the other based on ONC. DCE RPC by definition operates over communication services that incorporate distributed security services that provide support for authentication and message integrity and confidentiality services. ONC RPC can be used with a number of authentication flavours. An ONC RPC authentication flavour based on the GSS-API over a Kerberos mechanism is available and is being discussed within the IETF currently for standardisation. This ONC RPC authentication flavour provides equivalent support for authentication and message integrity and confidentiality services.

The use of such services is implemented below the RPC interface seen by applications and no change is required to the XFN RPC protocol to specifically address the use of these security services. This is illustrated in Security and XFN Protocol .

Figure: Security and XFN Protocol

The specification should include reference to these security services within the guidelines to implementors.

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