Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

User provisioning is a preparatory action for supplying a new user prior to initiating the user specific business services. This has several implications. Provisioning a new user may require creating a new user account in multiple applications across many systems. The user account may have multiple user credentials for the same person. Account mapping and provisioning for heterogeneous applications and systems is often complex. Password management, for example, involves resetting user passwords or synchronizing the passwords across multiple systems. This requires sophisticated control processes that can manage secure system interfaces and connectivity between the centralized password management system and the remote application systems. Since some user passwords can access sensitive business data, the password management control process needs to be highly secure, reliable, and timely.

In case of application service provisioning, it poses a different challenge when installing and configuring a new instance of a software application. Many software applications require manual configuration (such as creation of specific user accounts) due to the complex system design and local system settings. The manual configuration may result in creating variants of application system instances based on different types of hardware and software configurations.

Scope of Service Provisioning

The OASIS Provisioning Service Technical Committee notes that there is no standard definition of the term service provisioning in the industry (refer to [SPML10], p.10). In a broad sense, the term denotes the automation of managing and creating user accounts and its associated account services before and after the users can activate and use the business services. Service provisioning also include the preparation of the underlying operating system and server infrastructure, applications, the creation of user accounts and their associated service entitlement (for example, access rights and the entitled business functionality for the account), and the synchronization of user accounts and passwords across the rest of the enterprise architecture (including any large-scale vendor products such as PeopleSoft and SAP). Currently, Service Provisioning Markup Language (SPML) is an approved open standard for service provisioning to manage user accounts.

The scope of service provisioning may vary in different industry contexts. In the telecommunications industry, provisioning a subscriber account service means more than creating a user account in multiple business services (such as local call, distance call, or video-on-demand services) or creating user IDs in the online business systems. Some subscriber account services need to create account profiles for individual account services (such as a home video service bandwidth usage profile) based on product-specific business rules. Some subscriber account services have complex business rules and dependencies and may require some work-flow processes (such as credit approval and availability of local broadband cable infrastructure) to fulfill the account opening request. For example, provisioning a home video service account requires checking the credit, notifying the service provider to increase the network bandwidth dynamically for video streaming, creating a user profile that links up to existing business services, and so forth. Thus, there will be tight integration and complex interaction between business systems and the service provisioning system.

User account provisioning requires a tight integration with the application system (or application service provider) in order to create a new user account or identity. It may use a direct system interface that has a "root" or "super-user" access right in order to create or maintain the user account. Thus, user account provisioning needs to be extremely secure; if it is not secure, hackers or attackers will exploit any loophole in the system interface for harmful action or illegal access to business data.

Relationship with Identity Management

User account provisioning, a subset of secure service provisioning, is fairly different from single sign-on. The former denotes the creation of user accounts prior to using the business services and the management of passwords across systems. Single sign-on deals with the functionality to sign on to any system using a single user identity or a set of user credentials. It assumes that the user account and the associated account services are already in place; that is, service provisioning is complete. We should also differentiate the use of a directory server to provision user ID from secure service provisioning. The former is an implementation mechanism (or a means) for creating user accounts, but the latter implies a structured framework for creating as well as managing account services. Service provisioning may include using a directory server as one of the means to achieve security goals as well as other technologies and supporting service provisioning standards.

A Typical Scenario of User Account Provisioning

An employee may have multiple identities within the enterprise. For example, Figure 13-1 depicts a typical scenario in which Mary Jane Parker has recently joined the company. The IT administrator is going to create a user account for her in various application systems. The HR, CRM, and payroll systems require using her full name when creating a user account. Other computer systems have different user account creation rules. The ERP financial system uses her first and last name for her user account. The Messaging Server uses "maryj," and the directory server uses a mnemonic name, retep4yram. Mary may also be referred to as M_Jane or Mary.Jane when dealing with the Help Desk and external trading partners.

It is a nightmare for an IT administrator to provision a user account for a new employee across application systems with different user account creation rules and using multiple identities. The administrator also needs to determine whether the user account has the same access rights for all of these application systems. If the user account has different access rights in each application system, a change in the user account attributes (for example, a change in the user's department) would probably require a change in the access rights in other systems. If there is no automated user account creation interface across application systems, this kind of a change will require considerable manual administrative processing. If there is an automated user account creation interface, it may expose a security risk (such as weak security token, broken authentication, or broken access control) when exchanging user credentials and synchronizing user passwords with external application systems. Additionally, it is challenging to synchronize all user passwords for these user accounts. Administering the security provisioning servicesfrom creating user accounts to synchronizing user passwordscarries high administrative costs (refer to [Cryptocard] for details).

In the typical scenario shown in Figure 13-1, there are three implications to the security design and implementation. First, to provide a flexible identity management capability for multiple identities for different application systems requires reliability (for example, a failover mechanism in case the identity management infrastructure encounters problems), flexibility (for example, policy-based instead of hard-code rules), scalability (fit for a distributed environment), and maintainability (for example, reuse of security best practices and patterns). Unreliable user account provisioning will be exposed to potential security vulnerabilities such as insecure data transit, weak security token, broken authentication, or broken access control. Maintaining and administering identities and user accounts is more than a set of security administration procedures.

Second, to automate security service provisioning across application systems requires a standard interface (ideally, a standards-based interface) that works with the existing security infrastructure. If the interface is proprietary, there will be lots of integration and interoperability efforts required.

Third, there are needs for enabling proactive and reactive security protection measures to guard the user account creation interfaces among application systems or the password synchronization process among them. Message replay is a common security risk in such scenarios. Some service provisioning interfaces (such as an agent-based architecture) may require some software code changes in the underlying application infrastructure. Thus, they are "intrusive" to the security architecture. Some service provisioning interfaces may require sharing user credentials with external systems or trading partners, which may create a potential data privacy issue. Security architects need to understand the underlying mechanisms of these interfaces and ensure that the user account provisioning process and their interfaces do not expose new or unknown security risks.

Current Approaches to User Account Provisioning

To address the typical scenario illustrated in Figure 13-1, security architects commonly use the following approaches when building security service provisioning solutions:

• User Account Mapping. A mapping table can be created to map different user identities with different application systems. The authentication service component (for example, a directory server) may use an internal unique identifier to map to different user identity variants. When a user wants to access any application systems, the authentication service component looks up this mapping table and verifies whether the user can access any application systems. However, this is a tactical and proprietary solution. There is considerable customization effort required for the authentication service component and for integration with all application systems.

• Password Synchronization. Security architects use tactical and proprietary vendor solutions to synchronize user passwords in different application systems. These solutions usually have custom adapters or connectors that can populate user passwords into the target application systems. Synchronizing user passwords usually assumes that user accounts are created and provisioned in advance. The password synchronization products are specialized solutions and do not necessarily provision user accounts with different identities. Using tactical and proprietary vendor solutions can end up creating lock-in to a specific vendor's implementation and can make it fairly difficult to interoperate with new security infrastructure or emerging provisioning standards.

• Single Sign-on. A single sign-on security infrastructure allows a user to sign on to different security infrastructures. However, a single sign-on solution does not provide the functionality to provision user accounts in multiple application systems with different identities.

• Point-to-Point Interfaces between Identity Management Products. Custom point-to-point security interfaces can be built between identity management products (for example, a single sign-on or password synchronization product) to provision user accounts with different user identities. These interfaces are usually proprietary and require customization. If one of the identity management products has a version upgrade, the security interface needs to be upgraded as well in order to accommodate any necessary system changes.

• Standards-Based Security Service Provisioning Interfaces. The Service Provisioning Markup Language (SPML) is an XML specification for processing service requests for provisioning user accounts. The OASIS Provisioning Service Technical Committee approved it as a standard specification in October 2003. A number of security vendor products now support SPML. With SPML, security architects can define mappings between multiple identities and synchronize user passwords between application systems. SPML-based service provisioning systems can also work with single sign-on and portal server products.

Not all solution approaches address the entire problem of service provisioning. Most of these approaches are proprietary or vendor product-specific. They also may not be scalable enough to process user account requests for a large number of application systems simultaneously. SPML-enabled service provisioning is becoming more visible, especially after OASIS approved the SPML standard specification. Thus, customers can use a standards-based approach to address user account service provisioning. The following sections introduce the technical architecture of a service provisioning server and discuss how it can integrate with other infrastructure components, such as portal and identity service providers.