1.4 TSI roles

The next sections focus on the four key TSI roles and their supporting infrastructures: authentication, key management, authorization, and security administration infrastructures.

1.4.1 Authentication infrastructures

Authentication infrastructures are a TSI component that has been around for many years. In computing environments with high scalability requirements, it is not cost-efficient from an implementation and an administration point of view to create a separate authentication system for every individual computer system, resource, or application server. It is much better to outsource this functionality to an authentication infrastructure. Outsourcing also enhances the enforcement of a consistent authentication policy throughout the enterprise. Another major driver behind the creation of authentication infrastructures is single sign-on (SSO). SSO is covered in greater detail in Chapter 9.

An authentication infrastructure is made up of one or several authentication servers. Authentication security policies can be managed by the authentication TSI itself or, depending on the degree of centralization, using tools that come with the security management infrastructure. The authentication infrastructure interacts with a repository (a database or directory) to store and validate user credentials. Authentication servers will obviously be linked to an auditing system and may have management agents from the corporate IT infrastructure management software installed. Finally, the authentication services provided by the infrastructure will be used by a set of applications.

The authentication infrastructure software products that are available on the market today can be categorized as follows:

• Authentication infrastructures integrated with network operating systems. They are typically used in enterprise environments to ease authentication for accessing internal enterprise resources.

• Authentication infrastructures integrated with Web portal access management systems. They focus on authentication and authorization enforcement for resources that are accessible using a Web interface. Their scope goes beyond enterprise intranets and extranets—they can also be used for authentication and authorization on Internet portals. Also, these systems are not just providing authentication; most of them are integrated “authentication-authorization-security management” infrastructures. They are covered in more detail in Sections 1.4.3 and 1.5.2.

• Web authentication infrastructures. These infrastructures focus on authenticating Internet users that are accessing Internet resources.

  Table 1.1: Authentication Infrastructure Solutions

  Vendor	Product	URL
  Authentication infrastructure integrated with network operating system
  Microsoft	Windows 2000	http://www.microsoft.com
  Novell	Netware	http://www.novell.com
  Authentication infrastructure integrated with Web portal access management systems
  Netegrity	Siteminder	http://www.netegrity.com
  RSA	Securant	http://www.rsa.com
  IBM/Tivoli	Access Manager	http://www.ibm.com
  Web authentication infrastructures
  Microsoft	Passport	http://www.passport.com
  OneName	OneName	http://www.onename.com
  Novell	Digitalme	http://www.digitalme.com
  Jamcracker	Jamcracker	http://www.jamcracker.com

Table 1.1 provides a list of sample authentication TSI solutions out of the different categories listed above. Note that this is a nonexhaustive list: It does not give a complete overview of the authentication infrastructure products available on the market today.

Web-based authentication infrastructures are specifically Internetfocused; extranet access management systems (EAMS) are intranet- and extranet-focused and mainly offer SSO solutions for corporate Web portals. An important difference between both product categories is the entities controlling the authentication infrastructures. In EAMS, an organization’s IT department controls the authentication infrastructure. In most Webbased authentication infrastructures, control over the authentication infrastructure is outsourced to a commercial Internet authentication provider. The latter is not a rule, though: Novell’s Digitalme currently focuses on extranet SSO; Microsoft’s Passport currently focuses on Internet SSO, but may in the future also be extended to cover extranet SSO.

From this categorization it becomes clear that, to date, no universal authentication infrastructure is available that can provide SSO for Webbased Internet, intranet, and extranet resources, as well as for the resources in an enterprise environment. This may change as key management solutions such as PKIs gain wider acceptance and when some of the proven authentication protocols (e.g., “Kerberos”) are supported across multiple communication protocols and applications.

1.4.2 Key management infrastructures

A key management infrastructure’s primary reason for existence is, obviously, key management. Any security solution using cryptographic ciphers has to deal with cryptographic keys. When deploying these solutions in large environments, key management becomes a major issue. A scalable and easy-to-manage key management system is obviously of critical importance for authentication infrastructures used in large environments. The latter can be corporate intranets, extranets, or even the Internet. In such environments authentication keys would be hard to manage without using a centralized key management infrastructure. The use of TTPs makes authentication solutions scalable to very large environments.

Key management is certainly a big issue when using symmetric key ciphers. The use of symmetric key ciphers among many different entities poses important key distribution and key update problems. The problem is alleviated when using asymmetric key ciphers—but still it remains an important issue. Let me illustrate this using the following example: Setting up a symmetric key-based authentication solution between 10 people without using a TTP would require the creation and exchange of (10 * 9)/2 keys. This makes 45 keys total. When everyone trusts a TTP, only 10 keys would be needed. In the case of asymmetric keys the amount of keys needed remains the same, independent of the use of a TTP. However, the use of asymmetric keys has other advantages, as I will explain.

Based on the key material with which a key management infrastructure deals, we can differentiate between two different types of TTPs: key distribution centers (KDCs) and certification authorities (CAs). KDCs deal with symmetric keys—they can be linked together in multidomain or multirealm trust networks. CAs deal with asymmetric keys—they can be linked together in PKIs.

A key management infrastructure is made up of one or several TTP servers, whether CAs or KDCs. To enroll entities, key management infrastructures may use dedicated enrollment services (in PKI terminology, registration authorities). The registration authorities allow for a highly decentralized administration model. To provide access to these enrollment services to the widest possible range of users, most key management infrastructures provide a set of connectors. These usually include Web, wireless, and VPN connectors. Key management security policies can be managed by the key management TSI itself or, depending on the degree of centralization, using tools that come with the security management infrastructure. The authentication infrastructure interacts with a repository (database or directory) to store and validate user credentials. Key management servers are obviously linked to an auditing system and may have management agents from the corporate IT infrastructure management software installed. Finally, the key management services provided by the infrastructure will be used by a set of applications.

Table 1.2: Public Key Infrastructure Solutions

Vendor	Product	URL
Entrust	Authority	http://www.entrust.com
Baltimore (beTrusted)	UniCert	http://www.baltimore.com
Smarttrust	Security Center	http://www.smarttrust.com

KDC-based key management infrastructures usually come bundled with network operating systems such as Netware, NT, or Windows 2000. They can also be purchased separately: A good example is CyberSafe’s TrustBroker. TrustBroker is a Kerberos-based key management infrastructure product.

CA-based key management infrastructures can come as an add-on to a network operating system (NOS, e.g., Windows 2000 and Novell Netware), but generally high-end PKI products must be purchased as separate products. Big names in the PKI software space are Entrust, Baltimore, and Smarttrust PKI (as listed in Table 1.2).

1.4.3 Authorization infrastructures

Providing authorization services for employees to internal IT resources in a closed and homogeneous enterprise environment is relatively easy. Network operating systems such as Netware, NT, and Windows 2000 come with a set of built-in authorization management and enforcement features such as the ability to group resources in administrative domains, object models that support access control lists, security reference monitors (SRMs) bundled with the OS to evaluate and enforce authorization settings, and groups and rights to facilitate authorization management.

Things get much more complicated if the scope of the authorization infrastructure is broadened to cover not just internal users but also external users and if the resources can be accessed using different communication protocols and devices. Another complicating factor is the use of different applications that are using their proper authorization systems. Enforcing a single coherent authorization policy throughout an organization for all IT applications and services is an incredibly difficult task if every application and service maintains its proper authorization settings and makes its proper authorization decisions.

At this moment authorization infrastructures are certainly among the largest-TSI challenges that many companies have ever faced. For TSI software vendors, they are also a very hot topic: It seems as if vendors’ and customers’ interest is shifting from PKI toward authorization infrastructures and PMIs, or from TSIs that can only provide authentication services toward TSIs that can provide both authentication and authorization services.

When discussing authorization in the context of TSIs, we must consider the following authorization services:

• Authorization policy management deals with the creation of resources to be protected, groups, roles, access rights, permissions, and special access rules. Most important, it links users, groups, and roles with resources, access rights, and access rules. The administrator responsible for authorization policy management decides on the level of access that users have to resources (e.g., can John just read a file, or can he also delete it?). The latter process is also known as the creation of “permissions.” Resource, right, group, role and permission definitions are stored in an authorization policy repository.

• Authorization decision making is the real-time process of deciding on whether a user is allowed or disallowed to access a resource and the level at which he or she can access the resource. The input to this process is the information stored in the authorization repository.

• A resource manager is responsible for authorization enforcement. It makes sure that the authorization decision is executed correctly. In other words, he or she makes sure a user is allowed or denied access to a resource. Authorization infrastructures may enforce the authorization decisions themselves or delegate it to another trusted entity (e.g., an application).

In the early days of distributed client-server applications, every application maintained its proper authorization database, did its proper authorization decision making, and enforced authorization accordingly. There should be no need to explain that in such an environment, creating and maintaining a coherent authorization policy is a nightmare.

A first shift toward authorization service centralization came with first generation NOS, which centralized the definition of authorization intermediaries (objects like groups and rights) in a database. Because authorization enforcement is often very application-specific, applications kept on making their proper authorization decisions. Also, permissions remained to be stored in individual application authorization databases. Microsoft environments contain plenty of examples of this. The decision whether or not a user is allowed to access a particular NT workstation is always made by the workstation’s local security authority; likewise, the decision to access a SQL Server database is made by the database server itself.

To ease the creation of application permissions and to keep them coherent-throughout an environment with many different authorization databases and resource managers, software vendors created “provisioning systems.” I consider provisioning part of a security administration infrastructure and will discuss it in Section 1.4.4.

Another shift toward authorization service centralization occurred when extranet access management systems (EAMS) came to the market. EAMS centralize authorization decision making. In some products they also centralize authorization enforcement. I will discuss EAMS in more detail later.

The different shifts from decentralized to more centralized authorization services are illustrated in Figure 1.4.

Figure 1.4: Shift from authorization service decentralization to centralization.

An authorization infrastructure is made up of one or several authorization policy authorities. Authorization security policies can be managed by the authorization TSI itself or, depending on the degree of centralization, using tools that come with the security management infrastructure. The authorization infrastructure interacts with a repository (database or directory) to store and retrieve authorization data. Authorization infrastructure servers are obviously linked to an auditing system and may have management agents from the corporate IT infrastructure management software installed. Finally, the authorization services provided by the infrastructure will be used by a set of applications.

1.4.4 Security administration infrastructures

In a TSI environment the security administration infrastructure typically deals with security identity, authentication credential and authorization intermediaries, and policy management. To store this identity, credential, and authorization information, the security administration infrastructure uses a repository, typically a database or a directory. To provide more granular management capabilities, a security administration infrastructure may also provide self-service and delegated administration facilities for these data. Security administration infrastructures also guarantee that these critical data remain synchronized among the different repositories and applications of an IT infrastructure.

Security administration infrastructures often come integrated with other TSI solutions, such as authentication or authorization infrastructures. Examples are NOS such as Windows NT or 2000, or Netware, or EAMS such as Netegrity Siteminder and Oblix NetPoint.

For the moment there is one category of products that focuses on security administration infrastructure TSI functions. They are called provisioning systems and are discussed in a later section. Next we will explore the role of directories in identity management TSI solutions.

The important role of directories

Directories are commonly used as the central repository for security-related information. This information includes identities, authorization intermediaries (groups, roles), entitlements (what an identity is allowed to do), and identity or attribute certificates (produced by a PKI).

Lately, directories have been promoted as the cornerstone for enterprise identity management services. The main goal of identity management systems is to provide users with a single identity that can be used throughout the enterprise.

There are different technological approaches possible when using directories in the context of TSIs: using an enterprise directory, a directory synchronization utility, a metadirectory, or a virtual directory.

The concept of an enterprise directory is definitely the most straightforward approach to provide these functions to security infrastructures. The enterprise directory is the single authoritative source for identity information throughout an enterprise. All users and directory-enabled applications rely on the identities that are stored in the enterprise directory.

Unfortunately, many enterprises cannot use this approach because of the presence of legacy directories. They can choose the directory synchronization utility, the metadirectory, or the virtual directory approach.

Directory synchronization utilities are intelligent Lightweight Directory Access Protocol (LDAP)-based engines capable of synchronizing directory data between almost any type of directory.

A metadirectory (also referred to as a centralized directory) provides a consolidated view on data that are stored in different directories. It pulls the data together in a central repository and keeps them synchronized in the different directories.

A different approach to deal with multiple directories is the concept of a virtual directory. Unlike a metadirectory, a virtual directory does not build a central repository. It relies on directory server or client functions to access the data stored in different directory sources.

Table 1.3 gives an overview of directory solutions, one for every solution category: enterprise directory, metadirectory, directory synchronization, and virtual directory software.

Provisioning systems

Provisioning systems primarily deal with identity and resource provisioning. They allow companies to centralize and automate the process of supplying, or “provisioning,” internal and external entities with access to the company’s resources. In the mainframe era, identity and resource provisioning was relatively easy. The rise of the PC and the growing importance of distributed client-server applications have made provisioning an administrative nightmare. Provisioning systems extend the simplicity of mainframe provisioning to today’s distributed PC networks. Remember that a provisioning system does not authenticate users or enforce authorization—those are the tasks of other TSI components.

Table 1.3: Directory Solutions

Vendor	Product	URL
Enterprise directory
Novell	eDirectory	http://www.novell.com/products/edirectory/
Sun	Sun Java System Directory Server	http://www.sun.com/software/products/directory_srvr/home_directory.html
Metadirectory
Microsoft	Microsoft Indentity Integration Server (MIIS)—formerly known as MMS	http://www.microsoft.com/windowsserver2003/technologies/directory/miis/default.mspx
CriticalPath	Metadirectory Server	http://www.cp.net/solutions/wirelessSP/dataDirectoryIntegration/metaDirectoryServer.jsp
Siemens	DirX	http://www.siemens.com/directory
Directory synchronization
HP	LDAP Directory Synchronizer (Compaq LDSU)	http://www.hp.com/hps/messaging/mc_ldap_download.html
Virtual directory
Radiant Logic	Radiant One Virtual Directory Server	http://main.radiantlogic.com/RLISite/

Provisioning systems extend the ease of administration available in NOS environments such as NT and Netware to cover other applications and platforms. They provide a centralized administration layer on top of the NOS’ decentralized authorization enforcement. This makes them very different from EAMS (discussed later). In EAMS both authorization management and enforcement are centralized. Like NOS, provisioning systems are directory-focused to store identity, authentication, and authorization information.

The ultimate goal of a provisioning system is to provide a “one-click” administration system. For example, the deletion of an identity in the HR database will make the provisioning system automatically delete all other occurrences of this identity in all credential databases in your organization and all authorization settings of the resources of your organization. This can—if managed properly—significantly enhance the overall security quality of your IT systems. Used the other way around—to speed up the creation of new identities and authorization settings—it can make new employees become productive much faster. Obviously, centralized provisioning and one-click administration will also make identity and authorization management more consistent and easier to audit.

A provisioning system can do more than just identity and resource provisioning. These are major differentiators when comparing the functionalities of provisioning systems and identity management systems and metadirectory services. Most provisioning system software available on the market today is made up of the following services and components:

A self-service administration facility to let users maintain their proper credential and profile information

A delegated administration facility to delegate part of the administration of a subset of the accounts and/or resources maintained in the provisioning system to other administrators. This may be a muchneeded option in organizations with decentralized administration models or in the context of Internet or application service providers (ISPs or ASPs).

A password synchronization service to synchronize passwords between the different credential databases of an organization. This functionality may overlap with features offered by an authentication infrastructure providing SSO capabilities.

A workflow engine to automate the processes behind account and resource provisioning. For example, in many organizations the creation of a corporate account requires approval by multiple instances before the account is allowed access to the company’s knowledge base.

A set of agents or connectors to link up the provisioning system with applications and other TSI components

The most important partners of provisioning systems are directories and metadirectories. A provisioning system considers one particular directory, (e.g., the one that is managed by the HR department) as the master of identity information. This master directory will drive all the actions initiated by the provisioning system. In that sense provisioning systems can add great value to corporate directory or metadirectory deployments. They link up different applications with the directory—something that many directory vendors have not succeeded in doing when they tried to directory-enable various applications. When analyzing the provisioning market and the metadirectory market, it will become clear that much overlap exists between both product categories. Some metadirectories such as Siemens DirX are offering provisioning functions. In contrast, every provisioning system is LDAP-enabled to communicate with directories.

Table 1.4: Provisioning Solutions

Vendor	Product	URL
Business Layers	eProvision Day One	http://www.businesslayers.com
IBM Access360	enRole	http://www.tivoli.com/news/features/access360.html
Waveset Technologies*	Lighthouse	http://www.waveset.com

* The Waveset provisioning solution was acquired by Sun at the end 2003

It becomes clear that there are some obvious benefits to the creation of an identity and resource provisioning system as part of a larger TSI deployment. In the future their scope may even be extended. The provisioning systems available today focus mainly on application and database access. Vendors are currently looking at extending their products to cover other provisioning areas such as physical building access and application deployment. Table 1.4 gives an overview of provisioning solutions available on the market today (a nonexhaustive list).

Major players such as Access360 (now a part of IBM) and Business Layersare also involved in the provisioning standardization efforts. The main goal is to standardize and thus to simplify the exchange of provisioning information between different systems, resources, and applications.

Access360 leads the independent Extensible Resource Provisioning Management (XRPM) working group (more info at http://www.xrpm.org). The goal of XRPM is to standardize the exchange of access right provisioning information between different systems and resources in an extensible markup language (XML) format. The Active Digital Profile (ADPr) working group—which is led by Business Layers—has a broader scope. Its goal is to create an XML-based specification that will allow companies to share provisioning information across multivendor systems.