User Account Provisioning Architecture

Centralized Model versus Decentralized Model

Many service provisioning systems maintain a mapping of user identities and account services between application systems using a centralized provisioning server. The provisioning server can be a Java application that manages service provisioning requests and runs on top of a J2EE application server. Under the centralized model, the provisioning server can store user account profile information in multiple data stores (Profile Management Data Store). The provisioning server stores the user account information and user profile in the Profile Management Data Store in each application system. The Profile Management Data Store can be replicated and synchronized. This method allows better availability of user account provisioning services.

Figure 13-2 shows a sample centralized model. A client request from the help desk application intends to create a user account in PeopleSoft HRMS, SAP, and a home-grown application. The user account administration function of these applications should be able to process SPML requests to add, change, or delete user account requests.

Figure 13-2. Centralized service provisioning model

Figure 13-3 depicts a decentralized model, where there is no centralized provisioning server or profile management data store. User account profile information can be stored in local application systems. When the help desk application receives a client request to create user accounts in local application systems, it issues an SPML request to all application systems.

Figure 13-3. Decentralized service provisioning model

Under the decentralized model, a local application system can be configured as the Primary Profile Management Data Store, which acts as the master or provider and synchronizes user account profiles with other Profile Management Data Stores. In the sample scenario in Figure 13-3, the help desk application sends the SPML request to PeopleSoft HRMS, which acts as the Principal Profile Management Data Store. PeopleSoft HRMS then replicates the user profile across all application systems, including Sun Java System Directory Server, RSA SecurID, and Microsoft Exchange Server.

Table 13-1 summarizes the pros and cons of centralized and decentralized service provisioning models. There is no definitive rule about whether a centralized or decentralized service provisioning model is ideal. Architects and developers need to decide on the service provisioning model to use based on local requirements and environment constraints. For example, if customers have a large investment in an ERP system such as PeopleSoft HRMS around different regional offices worldwide, they may have a requirement to reuse existing application infrastructure and user credential repositories. Thus, they may find it sensible to adopt a decentralized service provisioning model by leveraging the ERP system to be the principal profile management data store.

Table 13-1. Pros and Cons of Centralized and Decentralized Service Provisioning
	Pros	Cons
Centralized Service Provisioning	It provides a single point of control. It has a relatively consistent user interface. It allows an automated provisioning process.	Centralized service provisioning may become a single point of failure.
Decentralized Service Provisioning	It is useful for a highly decentralized business environment.	Synchronization between provisioning data stores is highly complex. The decentralized model may result in inconsistent user interface and provisioning processes. The failover design scheme and capability is fairly complex, because the decentralized model needs to cater to a multitude of data sources in which the data sources may have a very different data management nature, resilience, and failover requirements.

Many service provisioning products support centralized service provisioning, for example, Thor's Xellerate and Blockade's ManageID. Some products also support both centralized and decentralized service provisioning, such as Sun's Sun Java System Identity Manager.

Logical Architecture

Figure 13-4 depicts the logical architecture of a service provisioning server. The provisioning server usually runs on top of a J2EE application server or a Web container. It has workflow processing capabilities that create, modify, or delete user account services in each of the SPML-enabled application systems. The provisioning server stores user profile and user account provisioning details in the local Profile Management Data Store, which can be implemented in an RDBMS (Relational Database Management System) platform using JDBC (Java Database Connector).

Figure 13-4. Service provisioning logical architecture for managing user accounts

There are two ways to issue service provisioning requests: from the client administrator and from an application system. The client administrator can use a Web browser to connect to the Web front-end of the provisioning server using the HTTP or HTTPS protocol. An application system, such as a help desk application, can also initiate service provisioning requests. It can connect to the provisioning server using different protocols, such as JMAC, ABAP, or JDBC. It can also connect to the provisioning server using a custom SPML-enabled agent or connector. Some provisioning server products provide an SDK or API library to build a custom agent or connector.

The extensibility and interoperability of service provisioning is always dependent on the capability to interoperate with different underlying platforms and application infrastructures. These include a variety of operating systems (for example, UNIX, mainframe, and Windows), RDBMS, directories, and custom applications. Thus, the provisioning server should be able to create, modify, or delete user account service by remotely executing user account administration functions provided by the target application systems using standard protocols such as SSH, 3270, JNDI, JDBC, and ADSI. The target application systems need to establish a secure and reliable connection with the provisioning server and be able to process service provisioning requests in the standard protocol (that is, SPML). The ideal service provisioning logical architecture should be able to support multiple application platforms, including UNIX applications, legacy mainframe platforms (such as IBM), and directories (such as Microsoft Active Directory and LDAP-based directory server).

A provisioning server has a number of logical components that enable service provisioning services. Figure 13-5 depicts generic logical provisioning components and the underlying provisioning services. The underlying provisioning services provide common and reusable functions that support the core provisioning capability, including monitoring, password management, and connectivity capability. The provisioning components are specific programs or applications that can interact with provisioning administrators. Individual provisioning vendor products have different names for these components, but most of them provide similar functionality.

Figure 13-5. Service provisioning logical architecture components for managing user accounts

Provisioning Components

There are several logical, reusable provisioning components in a service provisioning system:

Provisioning Server. This is the core component that processes service provisioning requests.
Monitoring. The monitoring component tracks the service requests received and processed, and provides statistics and logging information for audit control or administration support.
Password Manager. This component provides an administration function that manages user passwords for the target application systems. It utilizes the underlying password synchronization service.
Risk Analyzer. This administrative component analyzes any change impact from service provisioning requests or user account changes (for example, change of user roles) and provides system change information for security change risk analysis of the target application systems. It utilizes the processing rules and relationship defined in the rule engine (which is discussed later in this section).
Connector Factory. This administrative component manages the connection or interfaces between the provisioning server and the target application systems. In other words, this is the middleware function of providing APIs to connect the provisioning server to the target application systems using custom adapters or connectors.

Provisioning Services

In a service provisioning system, there are common services that use multiple provisioning components to complete the task of provisioning or de-provisioning a user account.

Rule Engine. This rule engine defines the service provisioning processes and security change impact.
Workflow Engine. This is a simple workflow engine that supports sequential or programmatic control of user account creation or any account service changes for service provisioning.
Synchronization Service. This is the underlying engine for synchronizing user passwords for the target application systems and for synchronizing the underlying Profile Management Data Stores.
Reconciliation. This is a simple reporting infrastructure for reconciling the user account service profile (target service provisioning plan) with the provisioned user account services (actual provisioning result).
Provisioning Discovery. This underlying service discovers whether there are SPML-enabled application systems in the network or infrastructure. Because there is no standard service provisioning discovery protocol yet, it may not be feasible for a provisioning server to discover different vendor-specific provisioning agents or proxies.

Provisioning server products have different levels of sophistication and functionality, and they may have logical architectures very different from this generic logical architecture. They may have several underlying provisioning services combined into one server component, or services that are split into more server components. Since an architect can craft the logical architecture in a variety of ways, provisioning server products may call these logical components by different names. It is not a trivial task to define a generic logical architecture for service provisioning servers.

Portal Integration

Administrators may sometimes have a special requirement to administer service provisioning requests via a portal server. The portal server provides a unified user interface for accessing different application systems using portal channels or portlets. Additionally, administrators can perform application administration from the same "console" without switching to different applications.

Figure 13-6 depicts how a provisioning server can integrate with a portal server. In this sample scenario, administrators can create a portal channel that connects to the system administration console of the provisioning server. Nevertheless, if the provisioning server has a fairly different user interface style, administrators might want to consider using the portlet approach. Using a portlet, administrators can customize a consistent user interface style for all applications and an administration front-end. The provisioning server needs to provide APIs that allow a portlet to initiate the administration console or process service provisioning requests. However, not every provisioning server supports portlet integration.

Figure 13-6. Integration with Portal Server

Integrating with an Identity Provider Infrastructure

Because administrators have a day-to-day need to administer multiple application systems, it is essential that they have the ability to access different administration consoles with a single sign-on capability. Administrators can also use a portal server to provide a unified user interface for performing system administration functions for multiple application systems. It is also beneficial to use an identity provider infrastructure that enables single sign-on to all application systems.

Here, the term "identity provider infrastructure" refers to software vendor products or application systems that enable single sign-on access and support single sign-on standard specifications, including SAML and Liberty. In other words, once the administrator provides user credentials to authenticate with a given identity provider, he or she can access the system administrative functions using the user interface provided by the portal server as well as any external systems outside the local system infrastructure (such as in a cross-domain single sign-on scenario). Even if the administrator is not performing service provisioning functions via a portal server, he or she can sign on once with the identity provider and access other application systems using an identity provider infrastructure.

Figure 13-7 depicts a single sign-on scenario where administrators authenticate their user credentials with an identity provider infrastructure. The identity provider infrastructure redirects the administrator to authenticate with an identity provider. Upon successful authentication, the administrator signs onto the portal server, which has an existing portal channel to connect to the administration console of the service provisioning server. The service provisioning server is configured to reuse the underlying directory server to store the user account profile and account information that are necessary to create or modify a user account.

Figure 13-7. Integration with Identity Provider Infrastructure

Under the single sign-on security infrastructure, each of the target application systems supports the Liberty and SAML protocol. These application systems are able to integrate with the identity provider infrastructure using Liberty and SAML-enabled Web agents. User account mapping between the service provisioning server and the target application systems is defined and managed by the administrative function of the service provisioning server. The user account profile is stored in each individual Profile Management Data Store of the target application systems. These data stores are synchronized periodically.

When the administrator issues a service provisioning request to create a user account in these application systems, the provisioning server can ensure that the same user account that was just provisioned can sign on to all target application systems for which the user account has appropriate access rights.

Other Integration Capability

Some provisioning servers have a broader integration capability with legacy system infrastructure. For example, they can reuse the underlying security infrastructure for storing user credentials and user profiles in the directory server. LDAP-based directory servers are fairly commonly used in authenticating and storing sensitive user account data. Such use is ideal for enterprises whose security architecture is concentrated in directory servers. They can store all service provisioning data in the directory server.

Differentiators for Service Provisioning Products

There are many ways to set evaluation criteria for service provisioning products in terms of their system functionality, pricing, and support infrastructure. There are also some specific differentiators that are unique to service provisioning products. The following outlines a set of differentiators that can help architects and developers to define the product evaluation strategy.

Technology Differentiators

There are technology-related factors that can differentiate service provisioning products. The following identifies some of them:

Agent-based versus Agentless Architecture. Some service provisioning products require installing a custom agent, which may need some software code modification, in their application infrastructure. This is also known as agent-based architecture. Agent-based architecture is generally not desirable and may require customization during software upgrades. Some products provide a nonintrusive connector that enables the target application system to intercept service provisioning requests. The connector may be a lightweight servlet running on top of the existing application server or Web server that doesn't require modification of the application system. This connector approach is sometimes called agentless architecture.
Data Model. Some service provisioning products use an index-based data model to encapsulate the user account profile or provisioning data. They implement the data model centrally in the Profile Management Data Store. Other provisioning products choose to implement the data model in distributed Profile Management Data Stores.
Extensibility. It is important to have an SDK that can build custom adapters for application systems that do not support SPML or service provisioning requests. Such an SDK allows extending the system functionality to accommodate service provisioning requests.
Data Integration. Some provisioning servers provide automated data integration with different Profile Management Data Stores or with the user account database of the target application systems. Some provisioning servers require manual data integration, such as creating data feeds to provision user accounts.