Background

Organizations interact with one another. They do so a lot. In fact, many organizations exist solely for the purpose of interacting with other organizations. Only particular types of organizations, such as retailers, schools, hospitals, social service agencies, and some government departments, focus on dealing with individuals. Among those organizations, a recent trend has been to reduce their activity to the ownership of their brand, relying on other organizations for manufacturing, logistics, and customer service (Means and Schneider 2000, 1-18). That trend is evident even in government departments outsourcing their activities to private enterprises.

Yet, despite the fact that their processes involve other organizations, the automation of those processes has mostly been kept stubbornly internal (Daly 2000). Organizations tend to design their automation to suit their own requirements, and make only the most rudimentary accommodation for their automated systems working together with those of other organizations.

This problem is especially evident in how information about the users of systems is managed. If the users of the systems of one organization are to be able to use them to access the systems of another organization, some information about those users must be shared for use in authorizing access to the other organization's facilities. However, not only is information about users seldom organized for access by multiple organizations, but it is also often not properly organized within any single organization. It is very typical for individual systems to be designed to have their own store of information about their users, so as people join or leave an organization, their information has to be added to, or removed from, each system's repository of user data.

As long ago as 1988, the organization that is now known as the International Telecommunication Union, and the International Organization for Standardization, released a standard for directory services called X.500. In the mid-1990s, the Internet Engineering Task Force began to publish a slimmer version of X.500 exclusively designed for TCP/IP environments, which is called the Lightweight Directory Access Protocol, or LDAP. The directory services defined by those standards are meant to serve as the central repository for every asset and user in an organization, and also provide a language and an application programming interface for querying that repository.

Microsoft Active Directory, which was initially released as part of Microsoft Windows 2000 Server, was Microsoft's LDAP-compliant directory service offering. In accordance with its corporate strategy at the time, Microsoft made Active Directory not only LDAP-compliant, but COM-compliant as well.

However, the adoption of directory services like Microsoft Active Directory tends to have been limited to managing access to network resources: to computer desktops, shared folders, printers, and electronic mail. It seldom extends to managing access to software applications, yet less to particular features of those applications or to the items of information they manage.

So anyone designing a software application today can be certain only of these articles of uncertainty:

• Although the users of the system may initially be a quite restricted group, perhaps including the members of only a particular department within an organization, if the application is useful, the community of users may expand, quite possibly to include users from other organizations.

• What may be known about those users in order to assess their privileges within the application could be quite unpredictable. Some users might be listed in a directory service, but others might not be.

• What the application may need to do in order to determine the privileges for which a user is eligible not only may be quite specific to that application, but also may need to change over time. Although it would be ideal for the application to simply query a directory service to determine a user's privileges, that seldom suffices.

Consequently, to secure an application today, one would like to have a technology by which access can be readily expanded to include a wider community of legitimate users with diverse ways of identifying themselves. One would also like to have flexibility in how one determines the privileges to which users of the application are entitled. XSI is intended to be just such a technology: a flexible and easily customizable way of controlling access to the resources of a software application.