Programming Security For Java Applications
|
 |
 |
|
|
 |
 |
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:
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.
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."
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.
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.
The Java Security Service Module naming authority supports the following types of 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 is either HTTP or HTTPSservername: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.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:
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.
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
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.
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.
Six different naming attribute types can be used with naming authorities.
SINGLE_VALUE_PREFIXMULTI_VALUE_PREFIXSINGLE_VALUEMULTI_TOKENSINGLE_VALUE_TERMINALMULTI_VALUE_TERMINAL Notice that you can group the attribute types into two categories: single and multiple.
Attribute types have specific behaviors according to their type. The following topics describe the behaviors of each type:
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.
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.
A single-value attribute can exist anywhere and is a single name/value pair. This attribute is the simplest and most generic.
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.
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.
You use the following classes to implement naming authorities:
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.
|
|
|