Each access control element plays an important role. Each must be assessed when evaluating multi-factor authentication and SSO solutions. Don't let your organization rush to implement streamlined login methods while ignoring one or more important test.
When assessing network, system, or physical access controls, temptation to merge identity verification, authentication and authorization into a single role-based access control (RBAC) activity is strong. Cost (both implementation and management) is often the driver. However, each of these three RBAC elements serves a specific purpose. Access control designers should consider each separately, as well as their relationships to each other, to achieve the most effective solution.
In this post, I walk through a conceptual examination of the elements of access control, how they each support an overall access control process, and caveats about selecting access control solutions which might skip one or more important tests.
Before continuing with a discussion about effective RBAC design, I need to make sure we’re all using the same definitions.
- Subject and Object. In access control speak, a subject is the entity attempting to gain access to a resource. Resources are called objects (e.g., network, application, service, etc.). Examples of subjects include users, business applications, and operating system services.
- Identity (verification). When a subject attempts to access an object, the first step should be to verify the subject is actually the entity represented to authentication and authorization mechanisms. Identity verification uses something known.
- Authentication. Once the subject verifies its identity, it must offer something it has, knows, or is to gain coarse access to objects. It must be authenticated with something no one else has or knows.
- Authorization. Granting access to an object must also include rights and permissions governing how the subject may use the object. This “fine-grained” access is authorization.
How RBAC works in a Windows environment
RBAC relies on clearly defined roles. Often the hardest, most time-consuming part of implementing role-reliant access, role definition is the responsibility of the data owners and business users. In a Microsoft Windows-based environment, IS Security, adhering to the principles of least privilege and segregation of duties, uses this information to complete the following for each role:
- Provide a means of enrolling new hires and existing employees into the organization’s identity verification system (i.e., biometrics, certificates, etc.).
- Determine what access to network or other information resources a role requires.
- Build a user account template and place it into new or existing groups, OUs, etc. which provide authenticated coarse access.
- Create system-level accounts for required applications with their own security repositories, including those using pass-through authentication. Define what information the role can see in the application and what the role can do with it.
Once identity verification, authentication and authorization controls are configured for a role, a user assigned to the role passes through a login environment similar to the one depicted in Figure 1.
The first “gate” through which a user must pass is identity verification. This is often a biometrics solution. Once the person’s identity is verified, an authentication gate is encountered. Passage is typically gained with a password, PIN, or other mechanism used to validate the user against a user acount in Active Directory.
Passing through the second gate provides the user with general, or coarse, access to the network and various resources. Resource accessibility is generally controlled via a combination of directory services and infrastructure configurations, including:
- Group membership
- OU placement
- Group policy objects
- VLAN/network segment access control lists (typically based on the device and how, or if, it authenticated to the network)
- Home-grown directories
Whether an application, such as the company payroll system, is accessible to the role is usually a function of authorization security built into the application. The information accessible by a user in a specific role and the actions the user can take on the information is defined within a proprietary application security framework. This is true whether a separate login is required for the application or whether the Active Directory credentials as used for pass-through.
In the example shown in Figure 1, the user has access to the network and, due to Active Directory group membership, access to the file and print server. However, the user is denied access to the payroll application, even though authentication allows access to the application’s login window, because no application account was configured for the role in which the user functions.
The first two gates are often combined into a single process, shown in Figure 2, in which presentation of a fingerprint or other token serves to verify identity as well as to authenticate.
Issues and recommendations
Again, identity and authentication functions are often combined into a single login activity. For example, certain biometric solutions enable both functions to occur as follows:
- The system might ask for an account name or other identity information, but this is not always required.
- The user places his or her thumb or finger on a biometrics sensor. The characteristics of the digit used are hashed into a “print value.”
- The scanned characteristics are compared against a set of print values stored on the local machine or a local server. If the print information is not found locally, a search is made of a central repository, often Active Directory.
- At this point, many organizations simply give the user access without any additional information or action required.
This approach begins to blur the lines between the three phases of access control. Adding single sign-on (SSO) can further obfuscate the process.
The goals of access control must include streamlining the user experience, eliminating unnecessary obstacles. However, this goal should be not be designed and implemented without thorough analysis of how identity is verified, authentication effected, and authorization enabled.
Identity verification is not authentication or authorization. Authentication is not identity verification or authorization… You get the idea. Each of these phases plays a specific role in access control. Each must be assessed when evaluating multi-factor authentication and SSO solutions. Don’t let your organization rush to implement streamlined login methods while eliminated its ability to properly guard the gates to the information stronghold.