Subscribe via RSS

Glossary

Glossary

Active Directory (AD)

Active Directory (AD) is an implementation of LDAP directory services by Microsoft for use primarily in Windows environments. The main purpose of Active Directory is to provide central authentication and authorization services for Windows based computers. Active Directory also allows administrators to assign policies, deploy software, and apply critical updates to an entire organization. Active Directory stores information and settings relating to an organization in a central, organized, accessible database. Active Directory networks can vary from a small installation with a few hundred objects, to a large installation with millions of objects.

Active Directory was previewed in 1996, released first with Windows 2000 Server edition, and revised to extend functionality and improve administration in Windows Server 2003.

Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This name remains in some AD binaries as well.

* Source: Wikipedia®, Wikimedia Foundation, Inc., August 10, 2007, via Wikipedia.org

Federated Trust

In information technology, federated identity has two general meanings:

  • The virtual reunion, or assembled identity, of a person’s user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
  • The process of a user’s authentication across multiple IT systems or even organizations.

For example, a traveler could be a flight passenger as well as a hotel guest. If the airline and the hotel use a federated identity management system, this means that they have a contracted mutual trust in each other’s authentication of the user. The traveler could identify themselves once as a customer for booking the flight and this identity can be carried over to be used for the reservation of a hotel room.

* Source: Wikipedia®, Wikimedia Foundation, Inc., August 10, 2007, via Wikipedia.org

Generic Security Service Application Programming Interface (GSSAPI)

The Generic Security Service Application Programming Interface (GSSAPI) provides a standard API for applications to use for authentication and secure messaging (confidentiality or integrity protection). The GSSAPI is presently the only such standard API, and is supported by a variety of vendors.

The GSSAPI is “mechanism independent,” meaning that different security mechanisms may be implemented underneath the common API. This allows the security mechanism to be changed without changing applications. However, in practice the only commonly accepted mechanism supported by most GSSAPI implementations is Kerberos 5. (The SPKM—Simple Public Key Mechanism—is defined for use with PK credentials, but SPKM has seen very little use.)

Microsoft and Sun also support the GSSAPI. Microsoft supports the GSSAPI at the protocol level in Windows 2000. However, the API used in Windows 2000 is slightly different than that GSSAPI, and uses the Microsoft-specific API known as the SSPI.

Internet Protocol Security (IPSec)

Internet Protocol Security (IPSec), provides integrity or confidentiality services at the network layer, and is the most common basis for VPN implementations today. All data protection is performed using symmetric-key cryptography. Establishment of the session keys for data protection is also defined by IPSec, and may use both symmetric and asymmetric-key cryptography.

While IPSec provides data protection, it does not provide the key management infrastructure necessary for a large number of IPSec systems to authenticate and establish the session keys needed for data protection. As a network layer protection service, IPSec is targeted primarily at machine-to-machine security. Authentication of individuals and applications is outside the scope of IPSec. It depends entirely on the key management infrastructure used and the integration of that key management infrastructure with the IPSec implementation.

Kerberos

The acceptance of Kerberos as a common authentication system has been limited until fairly recently. With Microsoft’s support of Kerberos in Windows 2000, and Sun’s support of Kerberos in Solaris and Java, the number of applications that will accept Kerberos credentials, and that can participate in a secure SSO solution with little or no additional effort, will dramatically increase.

Kerberos is a trusted third-party system that issues credentials conceptually very similar to a Public Key. In the Kerberos model, the trusted third-party is called the Key Distribution Center (KDC). The KDC issues credentials, called “tickets.” A Kerberos ticket is necessary in order to access an application that is protected by Kerberos. Kerberos credentials are typically issued with a lifetime of hours or days, instead of the months or years typical of Public Key credentials. For example, an employee authenticates once each morning, and the Kerberos credentials issued are good for that day only. The next morning, those credentials are unusable, and the individual must re-establish their association with, and right to access, enterprise resources.

Extensions to Kerberos also provide for the use of Public Key credentials for authentication, allowing Kerberos to integrate with Public Key systems. Integration may be at the individual level, where an individual uses a smart card or file-based Public Key credential as part of the initial authentication (e.g., in place of a password), or at the enterprise level, where Public Key may be used to establish a trust relationship between different enterprise KDCs. (Kerberos has always had this capability using conventional symmetric-key cryptography, but it is somewhat cumbersome.)

Unlike Public Key, an individual and the KDC may share an established secret, such as a password, and that password may be used for authentication. The protocol provides very robust and effective protection of password-based authentication. This makes Kerberos suitable for lower-cost applications within an enterprise, where Public Key client credential management costs are unacceptable. This also allows Kerberos to use existing legacy databases to, e.g., provide the initial secret. Kerberos also provides the ability to integrate any additional “pre-authentication” mechanisms, such as token cards and biometrics. These mechanisms may be used alone or in combination to achieve the required authentication strength.

Lightweight Directory Access Protocol (LDAP)

The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying directory services running over TCP/IP.

A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. The most common example is the telephone directory, which consists of a series of names (either of persons or organizations) organized alphabetically, with each name having an address and phone number attached.

An LDAP directory tree often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain name system (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry (or multiple entries). Its current version is LDAPv3, which is specified in a series of Internet Engineering Task Force Standard Track Requests for comments (RFCs) as detailed in RFC 4510.

* Source: Wikipedia®, Wikimedia Foundation, Inc., August 10, 2007, via Wikipedia.org

Public Key Infrastructure (PKI)

Public Key, or more accurately, asymmetric-key cryptography using X.509 certificates, is gaining acceptance as an authentication technology. In the Public Key model, certificates, which bind an individual to an identity, are registered with, and signed by, a trusted third party, the Certificate Authority (CA). As with any trusted third party system, the CA must be trusted by all parties involved.

While Public Key credentials, in the form of certificates and public-private key pairs, satisfy requirements for strong, distributed authentication, the credentials are cumbersome and require additional resources for a broad-based solution. The private key, which is the most important secret possessed by an individual, runs to hundreds or thousands of bits in length. Thus, a persistent storage system is required to hold the private key, and access to this storage must be protected using a more mundane and conventional mechanism, such as a PIN or password.

Conventional approaches to Public Key suffer from lack of tools and techniques for managing client credentials. Smart cards hold some promise for solving the problem of secure and mobile private key storage. However, this technology is still relatively new and expensive. The most costly part of the solution being not the cards, but the requirement that smart card readers be widely deployed. Lower cost solutions, which store the credentials on a local (e.g., workstation) disk file, suffer from mobility or security constraints. Conventional Public Key approaches also use credentials that are typically issued with a lifetime of months or years. Revocation of those credentials is still a problem, and scaleable and efficient solutions are not yet widely deployed.

Within the enterprise, client credential management problems have limited Public Key to a few selected applications. However, due to its ability to provide authentication without the prior establishment of a shared secret (e.g., a password) between the parties in a transaction, it has gained popularity in extranet-type applications. Although it has seen limited use due to client credential management problems, virtually all web clients and browsers are capable of Public Key authentication—an unfortunate and ironic situation. Also, a number of VPNs and e-mail applications also support Public Key. In some cases, such as VPNs, it is typical for the vendor to embed a single-purpose CA into their product. This is in part due to movement towards IPSec in the VPN area.

The application of Public Key for authentication and access control could provide significant benefits, if the client credential management problems can be solved. For example, secure web single sign-on is very feasible if we assume that all clients have Public Key credentials. The ability to transparently establish secure and authenticated VPNs would be greatly simplified if we assume that all clients have Public Key credentials.

secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) is a protocol used for secure point-to-point communications. The primary example of the use of SSL is in the HTTP and HTTPS protocols used by web browsers and servers. SSL has built-in capabilities for using Public Key authentication. However, that capability typically goes unused due to client credential management problems.

SSL is suitable for point-to-point security, such as is found in two-tier (client-server) applications. For n-tier applications (n greater than two), SSL does not provide the facilities needed for securely propagating the identity of the end-client and end-server(s) across a series of point-to-point connections. That eliminates the ability to securely delegate authorization across applications, and removes the ability to audit the identity of individuals through most transaction processing systems.

SSL’s most obvious application other than browsers is as a secure transport for simple point-to-point security, such as is provided by application-layer VPNs. However, it is questionable that the use of SSL for such a purpose has any significant benefits over the GSSAPI.

Security Support Provider Interface (SSPI)

The Security Support Provider Interface (SSPI) is the Microsoft version of the GSSAPI standard. SSPI provides a uniform interface for using compliant authentication protocols in Windows 2000. An application using SSPI on Windows 2000 can interoperate with another application using GSSAPI on another platform, using Kerberos mutual authentication. Four broad categories of APIs exist in SSPI: package management, credential management, context management, and message support. The Microsoft Windows 2000 implementation includes support for SPNEGO.

Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)

The Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), is a special GSSAPI mechanism that allows the secure negotiation of the mechanism to be used by two different GSSAPI implementations. In essence, SPNEGO defines a universal but separate mechanism, solely for the purpose of negotiating the use of other security mechanisms. SPNEGO itself does not define or provide authentication or data protection, although it can allow negotiators to determine if the negotiation has been subverted, once a mechanism is established. GSSAPI implementations that do not support SPNEGO cannot negotiate, and therefore the client and server must agree a priori what mechanism or mechanisms will be used.

Single Sign-On (SSO)

Single Sign-On (SSO) is a method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems.

The term enterprise reduced sign-on is preferred by some authors because they believe single sign-on to be a misnomer: “no one can achieve it without an homogeneous IT infrastructure.”

In a homogeneous IT infrastructure or at least where a single user entity authentication scheme exists or where user database is centralized, single sign-on is a visible benefit. All users in this infrastructure would have one or single authentication credentials. (e.g., Say an organization stores its user database in a LDAP database. All information processing systems can use such a LDAP database for user authentication and authorization, which in turn, means single sign-on has been achieved organization wide.)

* Source: Wikipedia®, Wikimedia Foundation, Inc., August 10, 2007, via Wikipedia.org

Virtual Private Networks (VPNs)

Virtual Private Networks (VPNs) are capable of providing a secure “tunnel” between systems or applications. VPNs are valuable for providing confidentiality and integrity protection of communications for applications that do not understand or implement those protections—the most obvious being legacy applications, and in particular, the protection of ids and passwords transmitted across networks to those applications.

Note that, just because an application uses strong authentication (Public Key or Kerberos), does not mean the application also provides confidentiality and integrity protection for transmitted information. While strong authentication mechanisms typically (but not always) provide the key material necessary to protect subsequent communications, you can’t assume an application is providing that protection.

In some cases, a VPN may be necessary to protect communications even for those applications which use strong authentication. In other cases, a VPN may simply be a convenience to remove the burden from the application developers. Another case to be made for VPNs is the ability to externally enforce policies on the protection of transmitted data, without the knowledge or cooperation of the target applications or systems.

VPNs generally fall into two categories: network-layer or application-layer. The market does not, as a rule, distinguish between these different types of VPNs. However, that distinction is very important if VPNs are used as part of a secure SSO solution.