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 vs. Discretionary Access Control
The next major choice that needs to be made reflects whether the organization is delegating the fine-grained, file-by-file access control and security policy implementation details to individual users or local managers or is retaining (or enforcing) more global policy decisions with its access control implementation.
Mandatory access control (MAC) denies individual users (subjects) the capability to determine the security characteristics of files, applications, folders, or other objects within their IT workspaces. Users cannot make arbitrary decisions, for example, to share a folder tree if that sharing privilege has not been previously granted to them. This implements the mandatory security policies as defined previously and results in highly secure systems.
Discretionary access control (DAC) allows individual users to determine the security characteristics of objects, such as files, folders, or even entire systems, within their IT workspaces. This is perhaps the most common access control implementation methodology, as it comes built in to nearly every modern operating system available for servers and endpoint devices. Typically, these systems provide users with the ability to grant or deny the privileges to read, write (or create), modify, read and execute, list contents of a folder, share, extend, view other metadata associated with the object, and modify other such metadata.
The choices of centralized versus decentralized architectures, and whether to use mandatory, discretionary, or nondiscretionary access control as a global policy are important decisions that must be made before you can start implementing your IAM project. You've also got to make another set of decisions regarding the specific roles, tasks, or responsibilities that individual users or groups of users must fulfill, and correlate that with your organization's information classification guide. Combining those two sets of information informs your choice of access control models: Do your security needs dictate a role-based access control, for example, or can you safely operate with something simpler such as subject-based or object-based control? And with that decision in hand, you can then start putting AAA servers in place, configuring their services, and loading up their control information. Now, you can start provisioning user accounts.
Almost every device on your organization's networks (and remember, a device can be both subject and object) has an operating system and other software (or firmware) installed on it. For example, Microsoft Windows operating systems provide policy objects, which are software and data constructs that the administrators use to enable, disable, or tune specific features and functions that the OS provides to users. Such policies can be set at the machine, system, application, user, or device level, or for groups of those types of subjects. Policy objects can enforce administrative policies such as password complexity, renewal frequency, allowable number of retries, and lockout upon repeated failed attempts. Many Linux distributions, and as well as Apple's operating systems, have similar functions built into the OS. All devices ship from the factory with most such policy objects set to “wide open,” you might say, allowing the new owner to be the fully authorized systems administrator they need to be when they first boot up the device. As administrator/owners, you're highly encouraged to use other built-in features, such as user account definitions and controls, to create “regular” or “normal” user accounts for routine, day-to-day work. You then have the option of tailoring other policy objects to achieve the mix of functionality and security you need.
Role-Based
Role-based access control (RBAC) grants specific privileges to subjects regarding specific objects or classes of objects based on the duties or tasks a person (or process) is required to fulfill. Several key factors should influence the ways that role-based privileges are assigned.
Separation of duties takes a business process that might logically be performed by one subject and breaks it down into subprocesses, each of which is allocated to a different, separate subject to perform. This provides a way of compartmentalizing the risk to information security. For example, retail sales activities will authorize a salesclerk to accept cash payments from customers, put the cash in their sales drawer, and issue change as required to the customer. The salesclerk cannot initially load the drawer