Skip navigation.
Downloads | Product Documentation | Support

Programming Security For Java Applications

# Naming Authority

A naming authority has two functions. First, it provides a scope for a name, which ensures that the name is unique within that scope. Second, it defines the format of the name, breaking the name into named fields separated by delimiters.

The following topics provide information to help you understand naming authorities and how they are used in Java Security Service Module (SSM) applications:

- Why Use a Naming Authority? on page 3-1
- Associating a Named Object with a Naming Authority on page 3-3
- Types of Authorities Supported on page 3-4
- Supported Naming Authority Attributes on page 3-6
- Pre-Configured Naming Authorities on page 3-8
- Naming Authority Classes on page 3-8
- Attribute Precedence on page 3-9

# Why Use a Naming Authority?

Naming something uniquely has always been an issue in software. As the number of objects grows within a software system, the need for unique names increases and the problems of managing that uniqueness become more difficult.

Some systems rely on a certain amount of randomness to create unique identifiers. These systems work well with distributed environments as they are based upon statistical models that allow multiple authors to generate identifiers randomly with the same effect as a single governing entity. The short-coming of this approach is that the statistical model permits duplication as the number of objects in the system grows—it only guarantees that some miniscule percentage of objects will have duplicate IDs. In addition, since the IDs are random, they do not contain an inherent structure, are difficult to read by humans, and are often difficult to optimize for query and retrieval.

A common system for generating unique identifiers (IDs) uses existing knowledge of uniqueness in the form of a system network ID or CPU serial number, in addition to other elements. This limits the requirements of the uniqueness within one computer system, that is, if an ID is unique within one system, then by appending a unique system ID to it, it can be unique within any distributed-system environment. While this reduces the scope of the problem in that it eliminates the possibility of duplication, these identifiers are, by nature, just as random as entropy driven mechanisms and are equally difficult to read or optimize.

Other systems employ an object registry model, where a central registry issues IDs to all software systems. The problem with using a central registry is that it can be quickly overwhelmed. To deal with this problem, systems employing the object registry model often segment their ID pool into several sub-registries which are then handled by multiple servers. In the case of numeric IDs, IDs 1-10000 might get allocated to server1, IDs 10001 to 20000 to server2, etc. This model, although having some similarity to a naming authority structure, still requires a central, master registry to determine what blocks of IDs are given to the helper systems, and so it is just a modified version of a central registry.

The Java Security Service Module Naming Authority provides solution to all of the problems associated with naming systems discussed thus far. The naming authority model employs the segmentation of responsibility present in a registry-based system, but expands it so that IDs become readable by humans, are hierarchical, and are easily optimized. Furthermore, cooperating naming authorities are independent of each other and are only responsible for guaranteeing uniqueness within themselves. Thus, using multiple naming authorities eliminates the performance problems inherent in systems that use a central registry. It also allows multiple systems to use the same names, because the naming authority model guarantees uniqueness by using different naming authorities.

## How the Use of Naming Authorities Guarantees Uniqueness

Could "Rose" from the nursing home be different from "Rose" from the flower shop? Such is the problem with names; the same ones are used to mean very different things. The Java Security Service Module Naming Authority remedies this problem. How?

Any name in the real world has an implied authority already. In the example above with the name "Rose," one authority is the residence list of the nursing home and another authority would is the inventory of the flower shop. Only in relating the name AND the authority can a person properly communicate the uniqueness of the name "Rose."

## How a Naming Authority Adds Structure

A name can contain more information than mere uniqueness. It can also have structure. For example, the name for a woman named Rose who works in a nursing home in the USA might include her first name and last name, Rose Bud. But in other parts of the world, her name may include both her maiden name and married name in addition to her first name, Rose Pedalsweet Bud. Therefore, the name "Rose Bud" in the USA has a different structure than "Rose Pedalsweet Bud" as it may be presented in other cultures. Within the authority of a specific nursing home, either name is sufficient to identify Rose as a unique person. By having knowledge of whether the nursing home is in the United States of America (USA) or in another place, such as the United Kingdom (UK), you can gain knowledge of structure of the name. For example, the naming authority for the residence list of the USA nursing home could be name USAResidenceList, and the residence list of a UK nursing home could be UKresidenceList.

# Associating a Named Object with a Naming Authority

If a naming authority is responsible for differentiating between names within a distributed system environment, there needs to be a way to indicate that one name is associated with a particular authority versus any other. Within a software system, this is easily done by providing a reference for a named object to its authority.

Outside of a software environment, a tree-based naming convention is often employed to enforce uniqueness and provide a visual separation of names within a system. One system that uses this method is the Internet domain name system (DNS). The domain name system is based upon some theoretical "root server" in which defines naming authorities, domains, sub-domains, and finally names. The root server provides a starting place for searching for naming authorities. In the Java Security Service Module, the Naming Authority Manager fills a similar role.

Figure 3-1 Comparison of DNS with a Java Security Service Module Naming Authority

By querying the root servers, you may discover that there are many naming authorities present. Some naming authorities that we are all familiar with are ".com", ".org", ".edu", ".us", ".biz". Just as these authorities are registered with the root server, Internet domains must be registered with the proper authority before they can be recognized as valid domains. The Naming Authority Manager serves to register naming authorities in the same way. Before a name of type "URLBASE" can be recognized as a valid name, the naming authority for "URLBASE" must be registered with the Naming Authority Manager.

# Types of Authorities Supported

The Java Security Service Module naming authority supports the following types of authorities:

- Sub-Authorities on page 3-5
- Peer Authorities on page 3-5
- Self-Referencing Authorities on page 3-6

## Sub-Authorities

Just as DNS naming systems can have sub-domains, the Java Security Service Module naming authority can have sub-authorities. A sub-authority is useful when a name contains one or more other formatted names within it. In the case of a URL, which is formatted as:

`protocol://servername:port/path/filename?arg1=val&arg2=val`

where:

- `protocol` is either HTTP or HTTPS
- `servername:port` is the name and port number of the system running the application. For example, the servername might be `cracker` and the port is typically `7001` for HTTP connections and `7002` for HTTPS connections.
- `path` is the directory on the server, such as `/wles/docs41`.
- `filename` is the page being served, such as `index.html`.
- The `args` are query_string arguments, such as `?SectionID=26&SubSectionID=398&ArticleID.`

A URL contains a `filename` portion that may be represented in the `URL:FILENAME` format:

`basename.extension`

By linking the `filename` part of the URLBASE naming authority to a `URLBASE:FILENAME` sub-authority, the `filename` can be further broken down into a basename and extension. Note that the sub-authority name `URLBASE:FILENAME` does not have to include the prefix `URLBASE:`, but by including the name of the parent as a prefix it can be distinguished as different from a generic `FILENAME` authority. This naming convention is described by the specific instance of the naming authority.

## Peer Authorities

In addition to sub-authorities, a Java Security Service Module naming authority can also contain references to peer authorities. A peer authority is more general in nature and exists in another authority namespace (such as at the top level). Using the same URL format described in the previous section, the `servername` portion might be represented by a DNS naming authority as:

`nodename.subdomain.domain.authority`

This effectively changes the URL format from:

`protocol://servername:port/path/filename`

to:

`protocol://nodename.subdomain.domain.authority:port/path/filename`

By referencing this general DNS naming authority (which may be referenced by many other naming authorities), your authority holds a dependency on this authority and may not function well without it. In the case of the URL, if a DNS naming authority were not present, the servername would merely be represented as `servername=www.bea.com` and so the naming authority would continue to function in a reasonable manner. If a naming authority absolutely requires another authority, then it must list the other authority explicitly as a dependency.

Sub-authorities, by their nature, inherit all the dependencies of their parent, plus their parent, in addition to any dependencies to peer authorities that may exist.

## Self-Referencing Authorities

An authority can also be configured to reference itself in a recursive manner. For example, if a list of an unknown number of arguments is present, an authority that represents the name of one argument can extract the first argument, represent it, and then reference itself for the remaining arguments.

# Supported Naming Authority Attributes

Six different naming attribute types can be used with naming authorities.

- `SINGLE_VALUE_PREFIX`
- `MULTI_VALUE_PREFIX`
- `SINGLE_VALUE`
- `MULTI_TOKEN`
- `SINGLE_VALUE_TERMINAL`
- `MULTI_VALUE_TERMINAL`

Notice that you can group the attribute types into two categories: single and multiple.

- Single-type attributes have one name and one value and are the simpler of the two types.
- Multi-type attributes have one name but can contain many values. Additionally, Multi-type attributes may also reference another naming authority to indicate that the values contained within it are governed by another naming convention.

Attribute types have specific behaviors according to their type. The following topics describe the behaviors of each type:

- SINGLE_VALUE and MULTI_VALUE PREFIX Attribute
- SINGLE_VALUE and MULTI_VALUE TERMINAL Attribute
- SINGLE_VALUE Attribute
- MULTI_TOKEN Attribute

## SINGLE_VALUE and MULTI_VALUE PREFIX Attribute

All prefix attributes (both single and multiple) must exist at the beginning of the name. The naming authority is considered invalid if it attempts to define prefix attributes anywhere else in the attribute list. However, you can use as many prefix attributes as are necessary in sequence at the start of an attribute list.

A prefix attribute provides a means for any name to be separated into attributes. The first parts are prefix attributes; whatever is left is then mapped to other attribute types. Consequently, single-value prefix attributes are the highest priority attributes in an attribute list.

Multi-value prefix attributes provide the same functionality as single-value prefix attributes except that they can represent more than one value. By associating this attribute with another naming authority, which may use another delimiter, this attribute can be decomposed further into other name/value pairs. As with single-value prefix attributes, multi-value prefix attributes are of the highest priority within a naming authority.

## SINGLE_VALUE and MULTI_VALUE TERMINAL Attribute

A terminal attribute (both single and multiple) is meant to indicate that a section of the name exists at the end of a name. Just as prefix attributes must exist at the beginning, terminal attributes must be at the end of a name definition. Many terminal attributes can be used when defining a name.

Terminal prefixes are the second most important attribute within a naming system. Once the prefix attributes are determined, the terminal attributes are evaluated and whatever is left is mapped to the remaining attribute types.

A `MULTI_VALUE_TERMINAL` attribute provides a mechanism where a single terminal attribute type can contain many values. In addition, it can also reference another authority for further evaluation.

## SINGLE_VALUE Attribute

A single-value attribute can exist anywhere and is a single name/value pair. This attribute is the simplest and most generic.

## MULTI_TOKEN Attribute

A multi-token attribute is a "catch all" for all the sections of the name that do not map to any other attribute by their placement. Consequently, a naming authority may only have one multi-token attribute defined or else it is considered invalid. Multi-token attributes join the remaining parts of the name together, using the naming authority primary delimiter (the first one in its delimiter list), into one value delimited by that delimiter. If a multi-token attribute references another naming authority, then instead of using its own primary delimiter, the attribute uses the primary delimiter of the referenced authority during a shallow token enumeration. For more information, see Registering a New Naming Authority.

# Pre-Configured Naming Authorities

A library of pre-configured naming authorities is provided with Java Security Service Module, for example, the URLBASE naming authority. However, these naming authorities should not be used without modification. Instead you can reference the pre-configured authority as the sole sub-authority of your own custom naming authority. For example, if the `BEA_URLBASE` naming authority references the pre-configured URLBASE naming authority, `BEA_URLBASE` inherits all of the fields and rules of the URLBASE authority but still has a unique identity of `BEA_URLBASE` allowing you to configure other `URL` types such as `PARTNER_URLBASE` and `COMPETITOR_URLBASE`. With this approach, you do not have to design your own URL naming authority and you can still have your own unique authority. On the other hand, if everyone were to use the URLBASE naming authority as is, it would defeat the purpose of using a naming authority, because there would be no way to differentiate between a BEA named object of `URLBASE` type and a Sun named object of `URLBASE` type.

# Naming Authority Classes

You use the following classes to implement naming authorities:

- AttributeValueEnumeration
- NameAttributeType
- NameAttributeValue
- NamingAuthority
- NamingAuthorityManager
- NamedObjects
- PolicyDomain

# Attribute Precedence

The `NamingAuthority` base class provides parsing services for all naming authorities that define a name in a valid way using attributes. Attribute precedence comes into play when a name contains fewer delimited pieces then there are attributes defined within the naming authority. During token enumeration, certain attributes must be discarded to properly map the remaining attributes to the relevant values from the name.

Note: Application developers may choose to implement their own naming authority to override this default behavior from the base class.

In the `NamingAuthority` base class, there is a specific order in which attributes are selected for elimination. Attributes are trimmed either right-to-left or left-to-right. For specific information on each type of attribute, see Table 3-1.

Table 3-1 The Order in which Attributes are Selected for Elimination

Attribute | Trim Direction | Placement and Order of Selection for Elimination
`MULTI_TOKEN` | Right-to-left | Multi-token attributes consist of leftover tokens after all the other attributes are evaluated. Consequently, this attribute is the first one trimmed from a parsed name.
`SINGLE_VALUE` | See next column | Single-value attributes assume their identity by place value. They can be placed either next to a PREFIX attribute, a TERMINAL attribute, or at the start of a name. Single value attributes that are placed in relation to a PREFIX attribute are trimmed from left to right. Single value attributes that are placed in relation to a TERMINAL attribute are trimmed from right to left Single value attributes that are in name definitions that do not contain PREFIX or TERMINAL attributes are trimmed left to right.
`MULTI_VALUE` and`SINGLE_VALUE TERMINAL` | Right-to-left | Both multi value and single value terminal attributes are treated with equal precedence in a name.
`MULTI_VALUE` and`SINGLE_VALUE PREFIX` | Left-to-right | Both multi-value and single-value prefix attributes are treated with equal precedence in a name.