of remote users. By 1984, it started to see widespread use in Unix-based server systems; Cisco Systems began supporting it and later developed a proprietary version that it called Extended TACACS (XTACACS) in 1990. Neither of these was an open standard. Although they have largely been replaced by other approaches, you may see them still being used on older systems.
TACACS+ was an entirely new protocol based on some of the concepts in TACACS. Developed by the Department of Defense and then later enhanced, refined, and marketed by Cisco Systems, TACACS+ splits the authentication, authorization, and accounting into separate functions. This provides systems administrators with a greater degree of control over and visibility into each of these processes. It uses TCP to provide a higher-quality connection, and it also provides encryption of its packets to and from the TACACS+ server. It can define policies based on user type, role, location, device type, time of day, or other parameters. It integrates well with Microsoft's Active Directory or with LDAP systems, which means it provides key functionality for single sign-on capabilities. TACACS+ also provides greater command logging and central management features, making it well suited for systems administrators to use to meet the AAA needs of their networks.
LDAP is a directory service based on the X.500 Directory Access Protocol standard developed by the International Telecommunications Union Technical Standardization sector (known as ITU-T). It was designed to take advantage of the IP protocol suite, which evolved after the adoption of the X.500 Directory Access Protocol. LDAP is often compared to an old-fashioned telephone directory. An LDAP server contains information about users in a directory tree, and clients query it to get details. Large enterprises maintain replicated LDAP servers at various points across the enterprise to facilitate quick response.
Each entry in an LDAP directory tree is a collection of information about an object, pointed to by a unique identifier called a distinguished name (DN). The DN represents the complete path in the tree to the desired entry. A set of named component parts called attributes hold the data for that entry. Various user attributes are typically stored in LDAP directories, including telephone numbers, physical addresses, postal addresses, and email addresses.
LDAP can also be used to authenticate user credentials by an LDAP command called bind. In the simplest case, bind checks the entered candidate password against the userPassword attribute (receiving either a success code or the error Invalid credentials).
Microsoft's ubiquitous Active Directory (AD), developed for Windows domain networks, uses LDAP versions 2 and 3. Active Directory is a proprietary directory service, which is part of the Windows Server technology base; while this means it must be deployed on a Windows Server platform, AD can support networks with virtually any mix of device types and operating systems. A server running Active Directory Domain Services (AD DS), called a domain controller, authenticates users and authorizes actions, verifying their credentials and defining their access rights. Active Directory Domain Services provide structured hierarchical data storage for users, printers, and services, as well as support for locating and working with those objects.
On a larger, multinetwork or multi-enterprise playing field, Active Directory Federation Services (AD FS) can allow the sharing of information between trusted business partners. AD FS can provide single sign-on to federated partners just as other federated identity management systems can.
Two more modern protocols are commonly used together to provide authentication services. OAuth 2.0 and OpenID Connect offer a related but competing approach to SAML.
OpenID Connect is an implementation of the authorization framework OAuth 2.0, facilitating the communication of attribute and authentication information. Whereas SAML specifically relays requests from a website, OpenID Connect can work to effect authentication with either a website or mobile application as the requester.
An OpenID Connect (OIDC) authentication sequence requires the selection of an OpenID identify provider. Once the IdP is known, OIDC operates as an authentication layer on top of the OAuth 2.0 protocol, allowing the relying party to request and receive information about the user from the IdP.
OAuth 2.0 is itself an authorization protocol. Using it, a client application can request access to a protected resource from the entity that owns that resource. The request goes to an authorization server, which must authenticate the resource owner, validate the request, obtain authorization from the resource owner, and then relay an authorization token to the resource server that hosts the protected resource.
In the OIDC authentication implementation, the relying party (RP) is an OAuth 2.0 application requesting an ID token from an OpenID Connect Provider (OP). The fields in the token will contain data (“claims”) about both the user (called the subject, or sub, and known by a locally unique identifier) and the timing (both the “issued at” time, or iat, and the expiration time, exp) of the authentication event. Also, the ID token will contain the issuer identifier (iss) of the OP and the client identifier (audience, or aud) registered for the RP at the issuer. Additionally, the claims can contain more information about the user, such as first_name, last_name, and so on. One way to view this extension of OAuth 2.0 is that OpenID Connect effectively allows an application to request authorization to authenticate a user.
IMPLEMENT ACCESS CONTROLS
Two more major decisions need to be made before you can effectively design and implement an integrated access control strategy. Each reflects in many ways the decision-making and risk tolerance culture of your organization, while coping with the physical realities of its information infrastructures. The first choice is whether to implement a centralized or decentralized access control system.
Centralized access control is implemented using one system to provide all identity management and access control mechanisms across the organization. This system is the one-stop-shopping point for all access control decisions; every request from every subject, throughout the organization, comes to this central system for authentication, authorization, and accounting. Whether this system is a cloud-hosted service or operates using a single local server or a set of servers is not the issue; the organization's logical space of subjects and objects is not partitioned or segmented (even if the organization has many LAN segments, uses VPNs, or is geographically spread about the globe) for access control decision-making. In many respects, implementing centralized access control systems can be more complex, but use of systems such as Kerberos, RADIUS, TACACS, or Active Directory can make the effort less painful. Centralized access control can provide greater payoffs for large organizations, particularly ones with complex and dispersed IT infrastructures. For example, updating the access control database to reflect changes (temporary or permanent) in user privileges is done once and pushed out by the centralized system to all affected systems elements.
Decentralized access control segments the organization's total set of subjects and objects (its access control problem) into partitions, with an access control system and its servers for each such partition. Partitioning of the access control space may reflect geographic, mission, product or market, or other characteristics of the organization and its systems. The individual access control systems (one per partition) have to coordinate with each other to ensure that changes are replicated globally across the organization. Windows Workgroups are examples of decentralized access control systems, in which each individual computer (as a member of the workgroup) makes its own access control decisions, based on its own local policy settings. Decentralized access control is often seen in applications or platforms built around database engines, in which the application, platform, or database uses its own access control logic and database for authentication, authorization, and accounting. Allowing each workgroup, platform, or application to bring its own access control mechanisms to the party, so to speak, can be simple to implement and simple to add each new platform or application to the organization's IT architecture; but over time, the maintenance and update of all of those disparate access control databases can become a nightmare.
Mandatory
