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
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.
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).
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
A provisioning server has a number of logical components that enable service provisioning services. Figure 13-5 depicts generic logical provisioning
There are several logical, reusable provisioning components in a service provisioning system:
Provisioning Server. This is the core component that processes service provisioning requests.
The monitoring component tracks the service requests received and
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.
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.
This is a simple reporting infrastructure for
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
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.
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.
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.
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.
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.
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
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.
There are technology-
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
architecture. Agent-based architecture is
Some service provisioning products use an index-based data model to encapsulate the user account profile or provisioning data. They implement the data model
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.