Designing a LACS solution requires agencies to consider the capabilities presented in the ICAM target state, existing LACS investments, and the agency‟s overall IT infrastructure. The objective of this effort is to determine how modernized LACS solutions will integrate with the agency‟s IT infrastructure and provide logical access services, as defined in the ICAM Services Framework (Section 3.2.4), to the agency‟s applications. This section provides a solution architecture diagram, discusses the components that comprise a modernized LACS, and introduces common characteristics that an agency should consider when designing its target state LACS. The information and guidance provided in this section is intended to provide answers to several common LACS architecture and design questions, including:
What does a modernized LACS infrastructure, compliant with the ICAM target state, look like?
What are the components of a modernized LACS infrastructure, and how do they support
achievement of the ICAM target state?
What common characteristics should I consider when designing a LACS solution?
11.2.1. Solution Architecture
The ICAM segment architecture presented in Part A describes the LACS target state and introduces logical access services as part of the ICAM Services Framework. One of the key characteristics of the target state is moving toward providing common logical access services (privilege management, authentication, and authorization) at an enterprise level. Many agencies within the Federal Government are moving toward this model and the purpose of this section is to illustrate how those services are aligned within a LACS solution. The solution architecture outlined in Figure 44 is intended to illustrate the concept of leveraging shared agency resources to provide a common set of logical access services across an agency‟s enterprise. The box at the center of the diagram depicts the LACS infrastructure with a variety of common components capable of supporting LACS services, as outlined in the ICAM Services Framework. These components represent generic products and are not aligned with a particular vendor or solution offering.
Figure 44: Logical Access Solution Architecture
The diagram above is intended to serve as a high-level depiction of the target state for LACS, and is representative of the many solution variations/designs that agencies may choose to implement. The solution components within the Enterprise Logical Access Infrastructure are represented generically and could be implemented using a variety of COTS and purpose-built products. This type of solution architecture provides both authentication and authorization services at an enterprise level for all protected resources, and is the recommended means of achieving the ICAM target state. The enterprise authentication and authorization solution is discussed further in Section 11.2.1.1. While it is expected that enterprise LACS services, as represented in Figure 44, will be the predominant solution model in the target state, this approach may not be appropriate for all agencies or for all applications within a particular agency. Situations may exist where it is either not feasible to deploy such a solution, or not practical or cost effective to integrate particular applications if such a solution exists. In support of these situations, sections 11.2.1.2, 11.2.1.3, and 11.2.1.4 discuss several of the most common variations on the enterprise LACS services solution architecture presented above and provide examples of where it may be advantageous to pursue an alternate approach.
11.2.1.1. Enterprise Authentication and Authorization
In the enterprise authentication and authorization architecture outlined in Figure 44, an agency‟s IT resources are integrated with one or more central LACS solutions that provide both user authentication and authorization services for the integrated resources. This model allows resource owners to leverage authoritative identity data, centralized authentication, and enterprise access control enforcement to streamline the management of users and privileges for their resource. This approach is recommended for a wide variety of departments and agencies,
particularly large independent agencies, agencies that are geographically centralized, or agencies with a large number of standardized web applications. Figure 45 highlights some of the potential benefits and limitations associated with the enterprise authentication and authorization solution.
Benefits Limitations
Agency aligns with the preferred model for achievement of the ICAM target state for LACS Agency needs can be supported by a number of
widely available COTS products/suites
Applications gain added security through use of a standardized authentication mechanism
Users may be able to experience Single Sign-On (SSO) capabilities across multiple applications User authorization decisions are based on
authoritative entitlement attributes and access privileges
Applications receive fine grained authorization decisions based on up-to-date user entitlements Agencies realize an enhanced ability to manage user
access across the user lifecycle
Agencies and resource owners gain an enhanced ability to detect and remediate compliance issues within resources (i.e. segregation of duties) and across one or more applications
Agencies have the ability to employ role-based access control based on user attributes
Agencies may require an up-front investment to build, configure, and deploy a LACS solution
Agencies may experience difficult and time
consuming deployment across the enterprise due to the complexity of the organization
Legacy applications may not easily integrate with an enterprise solution
Agencies may realize that an enterprise solution is not financially feasible, based on size and scope of deployment
Figure 45: Benefits and Limitations of Enterprise Authentication and Authorization
11.2.1.2. Enterprise Authentication and Decentralized Authorization
Some organizations may require a hybrid approach to providing LACS services whereby authentication is performed via enterprise authentication services, while authorization decisions are performed natively by the resource. For example, many web access management products, which could make up a part of an agency‟s enterprise authentication services, create and send an identity assertion to each protected application when the user attempts to gain access.81 The application itself accepts the assertion and relies on locally maintained access privileges to make a user authorization decision. Additional system components within the authentication services address other resource types, such as mainframe applications.
Terminology
Assertion – a statement from an entity that verifies a user’s identity, such as an enterprise authentication service, to a relying party that contains identity information about a user. Assertions may also contain verified attributes. Assertions may be digitally signed objects or they may be obtained from a trusted source by a secure protocol (e.g., Security Assertions Markup Language (SAML), Kerberos).
Agencies may choose this type of approach for legacy applications or in situations where it makes sense for a local resource to maintain control over user authorization. For example, certain legacy applications may be incapable of processing more granular authorization decisions (e.g., role- or attribute-based) or the application does not require robust or granular authorization
81 Examples of identity assertion-based authentication technologies that extend network login to applications while maintaining local
capability (e.g., applications with a single user role). Figure 46 highlights some of the potential benefits and limitations associated with decentralized authorization approaches.
Benefits Limitations
Applications benefit from the added security of a standardized authentication mechanism
Users may be able to experience SSO capabilities across multiple applications
Applications maintain local control over authorization decisions
Authorization decisions remain highly dependent on locally managed access privileges
Changes to the security model of the application require local code changes
Reduced ability to detect and remediate compliance issues within resources (i.e. segregation of duties) Authorization may be managed inconsistently across
the organization
Reduced ability to manage users across the user lifecycle
Resource owners must continue to maintain native reporting and auditing capability
Figure 46: Benefits and Limitations of Decentralized Authorization Approaches
11.2.1.3. Decentralized Authentication and Enterprise Authorization
Agencies may opt for an additional hybrid solution architecture, which utilizes a decentralized approach for user authentication while leveraging an enterprise authorization service. In this model, authentication occurs at a local level as applications are configured to accept and validate user PKI certificates. Authorization occurs via an enterprise role and entitlement management service provided by one or more centrally managed authorization products. This type of approach is generally applied in agencies with very diverse or complex applications that require custom connectors or service interfaces to accept authentication decisions, or for high-risk (e- Authentication Assurance Level 482) applications that require a direct link between certificate- based authentication and the user‟s session. Figure 47 highlights some of the potential benefits and limitations associated with decentralized authorization approaches.
Benefits Limitations
Authorization decisions are based on authoritative user entitlement attributes and access privileges Applications receive fine grained authorization
decisions based on up-to-date user entitlements Enhanced ability to manage user access across the
user lifecycle
Enhanced ability to detect and remediate compliance issues within resources (i.e. segregation of duties) across one or more applications
Ability to employ role-based access control based on user attributes
Less support for enhanced enterprise level services (i.e., enterprise event auditing, SSO, etc.)
Resource owners must continue to maintain native reporting and auditing capability
Reduced ability to provision users in an automated fashion
Authentication may be managed inconsistently across the organization
Solution viable only at an operating system level; cannot be easily scaled for multiple web applications Highly complex and onerous change management
processes
Figure 47: Benefits and Limitations of Decentralized Authentication Approaches
11.2.1.4. Decentralized Authentication and Authorization
A decentralized LACS model relies on the native authentication and authorization capabilities within each application to validate users and manage user privileges. When using the PIV credential, this approach is most often achieved by enabling applications to accept and validate
PKI certificates to perform user authentication, and then performing authorization against locally maintained access privileges. In the target state, it is expected that this type of approach will be used in organizations with a relatively small number of applications where implementing a centralized LACS infrastructure is not cost effective. An agency might also choose this approach if its applications are based on proprietary technology and cannot be easily integrated with enterprise services. Typically these organizations perform a cost/benefit analysis, as described in Section 11.1.2, and discover that the cost of deploying an enterprise services solution outweighs the benefits that could be achieved. Figure 48 highlights some of the potential benefits and limitations associated with decentralized LACS approaches.
Benefits Limitations
Lower up-front investment required to enable LACS Implementation is generally faster than enterprise
solutions
Resource owners maintain control over user authentication and authorization decisions
Low learning curve for managers and administrators
Inability to provide enhanced enterprise level services (i.e., enterprise event auditing, SSO, etc.) Resource owners must continue to maintain
application specific user account and privilege data Authorization decisions remain highly dependent on
locally managed ACLs
Reduced ability to provision users in an automated fashion
Authentication and authorization may be managed inconsistently across the organization
Reduced ability to detect and remediate compliance issues within resources (i.e. segregation of duties) No visibility into whether appropriate application
access on a per application basis creates policy violations when paired with other application access Inability to manage users across the user lifecycle
Figure 48: Benefits and Limitations of Decentralized Authentication and Authorization Approaches
11.2.2. Solution Components
LACS infrastructures consist of a variety of components, as shown in Figure 44, including shared agency resources that make up the core Enterprise Logical Access Infrastructure, authoritative identity stores, agency applications, and common components to support PIV card authentication. This section examines the individual solution components that comprise the Enterprise Logical Access Infrastructure. Each of these components can be provided by a variety of commercial off-the-shelf (COTS) software products, in-house agency resources, and custom built tools. Many of the components discussed may be referred to differently by different product vendors; the component names used throughout this section are generic representations meant to be descriptive of the functionality provided by the component. In some cases more than one product or solution may be required to achieve the level of functionality described below. This varies based on each agency‟s selected implementation approach, infrastructure, business, and operational requirements. Agencies should evaluate the core capabilities of each component discussed in this section when designing LACS solutions in order to ensure that software capabilities are consistent with the ICAM Services Framework, regardless of technology and terminology differences..
Privacy Tip
When customizing and configuring a COTS solution component or developing a purpose-built tool to address the capabilities discussed in Section 11.2.2 and its subsections, agencies must consider existing privacy requirements and regulations. Involving appropriate security and privacy personnel can help ensure that solution components are properly configured and capable of meeting data protection, transmission, storage, and disposal requirements.
11.2.2.1. Identity Manager
The Identity Manager is primarily designed to correlate identity attributes from a variety of authoritative sources for the purpose of provisioning user accounts to agency resources. When integrating with legacy applications, this may include integrating with the application‟s native user stores (locally maintained user information for administering access control) or providing service interfaces as a means of correlating existing user data with authoritative sources. The Identity Manager automates the provisioning process (i.e., creating, updating, deleting, enabling, and disabling user accounts in applications and/or directories used by enterprise access management solutions).
The Identity Manager manages an array of automated workflows that leverage technology to eliminate manual paper-driven provisioning processes.83 These workflows include self-service, approval, escalation, manual tracking of approvals, ticketing requests, etc. The Identity Manager eliminates redundant collection of user identity data at the local resource level and prevents violations of segregation of duty (SOD) policies by not allowing accounts and entitlements to be provisioned if they violate a policy. A variety of COTS and purpose-built products are available to serve as the Identity Manager within a LACS infrastructure. Deployment of an Identity Manager that provides automated provisioning capabilities supports achievement of Transition Activity 8.2, as identified in Section 5.2.2.4.
11.2.2.2. Access Manager
The Access Manager provides runtime authentication and authorization decisions; enforcement services for protected applications, networks, and operating systems; and can provide an interface for managing access privileges and policies. Within the target state LACS solution architecture presented in Figure 44, the Access Manager complements the Identity Manager by integrating with the directories provisioned by the Identity Manager. Typical products that provide Access Manager functionality offer flexibility and the ability to customize the way that they are integrated into the LACS infrastructure and in the services that are provided at an enterprise level.
The Access Manager performs session management, which enables a SSO experience from the user perspective, wherein a user only authenticates with the PIV credential once and can access protected applications, provided session and application policy allows it. This eliminates the need for users to authenticate multiple times, thereby streamlining the access process and creating efficiencies for end users. The authentication process occurs between the Access Manager and the individual application in a manner that is transparent to the user.
83 Provisioning processes, workflows, technologies, and characteristics of an automated provisioning capability are discussed in detail in Section
Terminology
Single Sign-On – a mechanism by which a single act of user authentication and log on enables access to multiple independent resources.
In practice, many organizations achieve a variation called reduced sign-on, whereby a user experiences single sign-on for a set of resources but is required to independently authenticate to a small set other resources due to resource-specific security
requirements or technical constraints.
The Access Manager can also serve as a standalone component, without the need to integrate with a dedicated Identity Manager. This is most often the case where an agency chooses to integrate its Access Manager with an existing directory (e.g., Active Directory). This model uses the agency‟s directory as its user store and relies on the Access Manager to manage policies and privileges in addition to making runtime authentication and authorization decisions. While this is a valid approach, the guidance presented in this chapter aligns with the preferred solution architecture outlined in Section 11.2.1.1 and assumes that the Access Manager is integrated with an Identity Manager component, unless otherwise indicated.
Lesson Learned
LACS architectures that use a standalone Access Manager (i.e., not integrated with an Identity Manager) may not be a viable solution for agencies that do not have a single authoritative user store, as there is no way to ensure uniqueness of users across the enterprise.
A large federal agency attempted to implement a standalone Access Manager solution with disparate data sources and quickly discovered this problem. By implementing an Identity Manager, the agency was able to create unique digital identities and
successfully complete their LACS modernization effort.
A number of COTS and purpose-built products are available as an Access Manager and often include a variety of pre-built or custom resource agents and service interfaces, which are used to integrate with the application and provide enterprise authorization services though policy decision making and enforcement. These agents and services allow the application to intercept unauthenticated and/or unauthorized access attempts to ensure that applications are properly protected. When designing a LACS solution agencies should consider the types of web applications that exist within their IT infrastructure and select an Access Manager that most closely aligns with the agency‟s existing investments and infrastructure requirements; this topic is discussed further in Sections 11.1.2 and 11.3.2.
11.2.2.3. Role Manager
The Role Manager integrates with the Identity Manager and supports the process of engineering roles that can be consumed by the Identity Manager and utilized in the provisioning process. Role engineering can be performed in either a top-down (step-wise definition of roles based on organizational characteristics) or bottom-up (mining existing entitlements from applications) fashion or some combination of the two. By assembling individual entitlements into logical groups the Role Manager supports business friendly RBAC.84
84 The definition of user roles and access control polices within an organization along with a discussion of access control models is provided in
The Role Manager supports SOD policies by preventing the creation of roles that include access entitlements in violation of established policy. The Role Manager allows business owners, resource owners, and resource administrators to revise existing or create new access control rules/policies as business and operational requirements change over time. A variety of COTS and purpose-built products exist to perform Role Manager functions. Many of these products are designed around role-based access control with the emergence of more granular models, as described in section 9.3, as many commercial vendors offer tools which provide greater support. When designing a LACS solution agencies should closely evaluate the Role Manager‟s ability to interact and interface with other LACS components (both existing and new).
11.2.2.4. Directory Server
The Directory Server manages user identity data in a directory format and supports the identity