Case studies can illustrate how IBM handles a wide variety of business challenges that SOA is leveraged to solve, and they can help you see how you can use SOA to solve your own business challenges.
Part 1 in the series focused on two case studies. Case study 1 focused on customer order analysis. Case study 2 focused on a tracking system and microelectronics factory in a box. In addition to the business context, the article described the challenges that each of the case study projects had to overcome, and it illustrated the architectural overview of the resulting solution, along with the enabling technologies and tools. The article also described the tangible business results achieved by each project, and the harvested best practices and lessons learned that are being applied across IBM and with IBM clients.
Part 2 in the series explored two other case studies. Case study 3 focused on export validation service to assist with regulatory compliance. Case study 4 focused on a central customer master system.
This article presents the remaining case studies using the same approach. Case study 5 focuses on identity management for external business partner applications. Case study 6 focuses on IBM customer and business partner identity management and entitlement for IBM Web site users. Some of the case studies described in the first two parts are industry specific. Unlike those studies, initiatives described in this part represent commonly occurring cross-industry scenarios.
Case study 5: IBM Intranet Password External (IIPx)
Case study 5 focuses on identity management for external business partner applications.
As IBM internal Web applications began to proliferate, IBM employees had to manage multiple IDs and passwords, because each of the early applications developed their own unique authentication mechanism. After the mid-1990s, it became obvious that a single, worldwide authentication facility was required for all IBM internal Web applications to provide a single ID and password credential for each IBM employee. The IBM Intranet Password (IIP) function was developed and deployed as a common solution to enable identity management for internal applications. Unfortunately, the objective of IIP for a single ID and password for each IBM employee was not fully realized because of the numerous IBM Business Partner sites and applications that IBM employees use to do their normal IBM-related work. These external, third-party vendor Web sites include outsourced travel reservations, management surveys, retirement benefits and planning, a mentoring program, and an IBM bookstore. The application providers had unique ID and password schemes for each of their systems, which caused IBM employees to still require multiple IDs and passwords in order to access their applications.
When IBM employees used partner-provided business applications, they needed to use different authentication solutions that each of the applications implemented. Each business partner normally created user authentication credentials (usually just ID and password combinations) for users of their sites, and each established rules for valid passwords and password expiration. IBM employees wasted time keeping track of and resetting multiple IDs and passwords on these external Web sites while performing IBM business-related functions.
Because of their unique authentication systems, IBM partners had to provide adequate help center coverage for calls from IBM employees requiring credential assistance. In addition, the overhead costs related to the development and management of authentication management solutions and business rules had to be recovered in contracted charges to IBM.
The need for authentication across multiple partner applications to improve employee satisfaction and reduce costs became obvious. In order to manage the authentication of IBM employee credentials, some business partners requested a copy of the IBM employee LDAP directory, along with periodic updates. To maintain IBM internal network integrity as well as to employ privacy, IBM could not share employee data outside IBM or allow partners access to the IBM internal network for direct use of the internal LDAP instance. Any solution to the problem was also constrained by security systems already in place.
A solution was needed that ensured the following constraints were met:
- Minimum impact to existing applications. It was not realistic to require each business partner to perform major work to implement the new solution.
- Existing IDs and passwords were honored for these applications. Another objective was to make the transition as easy as possible for IBM employees.
- A relatively simple solution for business partners to implement. The solution had to be secure, but business partners were not interested in a solution that required a great deal of work for them or that would require their ongoing effort to maintain the passwords.
The resulting SOA-enabled solution, named IIPx, is shown in Figure 1. IIPx is an authentication utility that uses the IBM intranet ID and password to gain access to external Web applications. IIPx is based on the foundation laid by the earlier deployed IIP solution that provides employee identity management for internal applications.
Figure 1. IIPx architecture overview
External applications use an IBM-provided Web service to verify the identity of an IBM employee. This service validates a token, which is a digitally signed XML document. IIPx creates the token after the IBM internal IIP authenticates the employee. IIPx performs native LDAP authentication using an internal directory. After the user's credentials are authenticated internally, his browser is redirected to the external site, along with the token.
The following is a step-by-step description of a typical IIPx login session depicted in Figure 1. The numbers in the description correspond to the numbers in the figure:
- An IBM employee links to a business partner Web site. The IBM employee follows a link containing a vendor identification code to the IIPx login page. This happens on the IBM internal network (referred to as w3). The link is typically a button or URL to the IIPx logon page inside IBM.
- Authentication happens through w3.
- The employee enters IIP login credentials. This is the IBM employee's normal internal ID and password.
- The IIPx server validates the IIP login the same way any internal IBM employee's credentials are authenticated.
- The IIPx server creates an XML document containing basic employee information that is retrieved from the internal IBM employee directory, known inside IBM as BluePages. This document is passed to the vendor to provide information about the employee visiting the Web site.
- The IIPx server creates a digital signature for the XML document. This signature is based on a common IBM master key, which is available only inside IBM.
- The IIPx server generates an HTTP redirect URL containing the encoded XML document and signature, and the server returns the URL to the client browser on the employee's desktop.
- The authentication token is passed.
- The client browser follows the redirect URL to the third-party Web site.
- The third-party site retrieves the XML document and signature from variables in the URL.
- The third-party site passes the signature and document to the IIPx Web service at IBM (SOAP interface). This IBM-hosted service is available on the extranet to business partners.
- The IBM IIPx external Web service validates the match between the document and the signature. This ensures that the key does match, meaning the login came from IBM and the data is correct. The service returns a positive result.
- The third-party site establishes the user's session, and the flow continues through the vendor's site.
In order to manage the actual deployment of IIPx, a concept of incremental on-boarding was used. The idea is that applications can continue to operate their existing authentication functions while the new functions are being deployed. For a short cut-over period, it was possible to use both the older and newer IIPx authentication. Once fully tested, the previous authentication could be turned off.
The incremental on-boarding also stipulated that there was no single cut off date for all the applications. This enabled each business partner to determine a schedule for cutover that made sense for their application and was feasible given his own work load. Incremental on-boarding was also helpful to IBM employees by giving more time for awareness of the changes to be rolled out to all users.
The IIPx solution received quick acceptance and positive feedback from partners and employees. The introduction of this new authentication function was virtually transparent to employees. Through the implementation of this service, IBM achieved business flexibility that enables adding new employee users and managing the IDs and passwords from within the established IBM mechanisms. IBM employees now have an improved extranet experience with a single ID and password to remember, and employees perform no special steps to invoke these external, vendor-managed application Web sites. IBM business partners achieved measurable cost-avoidance by using this service. Business partners do not need to set up IDs and passwords for users, nor do the partners need to maintain these password systems.
Best practices and lessons learned
The implementation of IIPx reused the IIP implementation, which was a proven IIP service. This reuse clearly demonstrates the flexibility of SOA. IIP is implemented internally for IBM employees to access internal applications. The authentication model and Web service allow this function to be used from outside IBM, gaining the benefit of this function without compromising security or the integrity of the IBM employee directory.
Although IBM business partners quickly accepted this solution, it took time to convert their individual solutions. Some of the delay resulted from their schedules, availability of resources, and other business constraints. However, the concept of incremental implementation enabled the IBM business partners to define individual and non-disruptive conversion paths on schedules that met their needs. The result is a logical phase-in of the new function on an application-by-application basis without the pressure of a specific timeframe hanging over the project.
The SOA interface using Web services provides a secure and accurate solution for the authentication of an employee's credentials, not only across enterprise, but also across multiple external partners. The interface is difficult to spoof because of the way that the security credentials are passed to the business partner. Credentials are passed as parameters on the URL. Subsequently, the business partner uses the IBM extranet Web services, essentially asking IBM to validate those credentials. This match allows both the employee and the business partner to have confidence that the employee is identified correctly and should be given access to the function and data to which the employee is entitled.
The IIPx team also used incremental on-boarding of legacy applications that allowed for a non-disruptive transition path. Some applications already had ID and password systems set up before IIPx. Those partners can transition to this method as their development completes, and they can even allow for both the new and older forms of authentication until over the cutover is complete.
Finally, IIPx is a success because it did not require all IBM employees to acquire new IDs and passwords just to access vendor-managed IBM functions. The majority of IBM employees probably do not realize that these applications run in an environment outside of IBM, because the transition to the business partner Web site is virtually seamless. This almost-transparent implementation or migration to new function is generally a goal of most projects, but it is often not achieved.
Case study 6: Customer IBM Web Identify -- identity management and entitlement for users of the IBM Web site and related functions
The www.ibm.com domain is a collection of Web sites and associated applications IBM uses to present information to and interact with customers and business partners. In addition to direct e-commerce and recruitment Web sites, this domain includes portals where business partners can find information about manufacturing, procurement, or delivery information.
The various external IBM Web sites that support customers and business partners required their users to have unique user credentials (user IDs and passwords) for each site. To register, customers and business partners had to submit essentially redundant basic registration information, such as name, address, and email address, for each external site. Although a few common authentication and registration solutions were deployed for isolated domains of sites (such as Software Developer Support), users were required to maintain multiple credentials to access a variety of IBM Web sites. In addition, resources were also wasted across the various Web applications, each developing, deploying, and maintaining their own user ID and password authentication functions. This was a source of customer dissatisfaction, which needed to be addressed with a common IT solution for the entire IBM enterprise, similar to the (IBM Intranet Password) solution.
In order to ensure that the information in the ibm.com domain is kept secure and delivered only to those who are authorized, an authentication system has always been one of the critical functions. Unfortunately, with the growth of the Internet, many different password schemes proliferated as the various IBM Web application development teams created them for business partners and customers to use.
At the time, a central directory for external users did not exist; therefore, IBM Web applications could not share identity and registration information about their users. Each Web page or application that IBM deployed for IBM customers and partners had to collect its own authentication information. In addition, each application established different user ID and password requirements (such as the number and type of characters for allowed passwords). This was time consuming for users, and it took too long to install new applications.
A common, enterprise-wide solution was required to provide a single user ID and password for each customer and business partner to sign on to any of the Web applications on the ibm.com domain. The solution had to enable each application owner to manage the application access rights individually.
Because many applications had their own authentication solutions, business partners already had their own registered users. One goal was to migrate as many of these users into the new system as possible, accommodating different formats for user ID and passwords that already existed. Ideally, the external user should not have to reregister or even be aware that a new system was managing the authentication behind the scenes. The resulting Web Identify service needed to support all these requirements in one solution.
The Web Identify (WI) system provides ibm.com applications with information about users. It collects user profile information in a central data store, and WI makes it available through a Web Services interface. The profile information includes standard elements, such as user name, address, content preferences, interest areas, and marketing permissions. In addition, it also provides some application-specific data. Collecting profile information in a centralized place reduces the fragmented view of ibm.com, and it makes future Web personalization possible.
WI also provides access to authentication services, allowing applications to authenticate users and manage groups and roles.
Finally, applications can share session information through the WI system, eliminating the need to pass information through URL parameters or cookies.
Web Identify has an on-boarding process that applications use to describe roles and rights associated with the application in the Web Identify tool. Web Identity provides the LDAP-based directory services to enable application administrators to assign users to roles, which applications use to manage user authorizations.
The steps to use the Web Identify functions are performed using a Services Oriented (SOAP) interface:
- On-boarding the application.
- Setting up a user ID and profile.
- User signing on to the application.
On-boarding the application
This section describes getting the applications set up within WI and the ongoing function of approving user requests for access. Each application assigns one or more administrators to control user access to its functions. For some applications, the administrators are IBM employees responsible to manage their respective sites, while, in other cases, the administrators are business partners responsible to manage the authorization of their companies' employees to applications in IBM Web sites developed to interact with partners. The administrator works with the WI team to define the application including what roles and access levels should be set up with the specific application. On an ongoing basis, the administrator reviews access requests from new users and assigns them to a specific role associated with the application. This allows users to acquire access rights to a number of IBM applications that they need to use.
Setting up a user ID and profile
From the external user's point of view, the WI Web site allows users to create user IDs and passwords for themselves. Thereafter, users maintain their user IDs and passwords independent of the applications they access. In addition, the Web site enables the user to register and create a profile of basic information (such as name, address, and email address) and to declare what parts of the site or the IBM offerings he might be interested in. Initially, a user ID is not associated with any specific application areas and has no privileges. To obtain access, the user requests access to a specific application, including specific roles or access levels, based on the user's needs. Upon approval, the user might sign on to a specific application and use those functions.
Figure 2. Web Identity architecture overview
User signing on to the application
The following is a description of a typical session depicted in Figure 2. The bullets in the description correspond to the features depicted from left to right:
- A user can access functions from the ibm.com system and is authenticated using the Tivoli Access Manager (TAM). TAM performs the authentication function with the user and either accepts or rejects his sign-on.
- After the user's credentials are authenticated, the session is passed to the WI Adopting Applications to perform the functions.
- The WI Adopting Applications have access to user security, profile, and session information through a series of calls or Web services that enable applications to obtain specific information about the user.
Authentication and authorization functions
WI provides services to retrieve the user's credentials and profile information after the user starts a session. Services allow the application to retrieve user's basic registration profile, as well as the applications and roles to which the user is assigned. This enables the applications to collect more detailed information about each user to help customize user sessions on any of the ibm.com Web sites.
Table 1 shows some of the services available.
Table 1. Web Identity functions
|authenticateUser||Authenticate a user's credentials|
|addToGroup||Make a user a member of a group|
|isGroupMember||Determine if a user is a member of a group|
|removeFromGroup||Remove a user from a group|
|createIdMapping||Associate the IR ID with another ID. Aids in migration|
|getIdMapping||Get the associated ID for an IR ID|
|removeIdMapping||Remove the ID association|
|addToRole||Assign a user a role|
|isRoleMember||Determine if a user is in a given role|
|removeFromRole||Remove the role from a user|
|resetPassword||Reset a user's password|
First deployed in 1999, WI has been successfully used with ibm.com applications. Existing applications gradually converted their authentication and registration functions to use WI. This migration accelerated after 2003, when WI was officially defined as the IBM corporate external authentication standard.
Using WI improved customer satisfaction and increased efficiency, both for the application users as well as application developers and administrators. Customers, business partners, and the developers using the Web Identity system confirmed the improvements.
Today, WI is used by more than 200 applications accessed through over 1000 Web sites within the ibm.com domain. More than 3.5 million IBM customer, partner, and supplier IDs have been established within Web Identity.
Since 1999, the cumulative application cost avoidance resulting from Web Identity use has been estimated at $47 million. During this time, IBM has spent approximately $11.8 million on the development and deployment of Web Identity.
Best practices and lessons learned
Some of the key lessons learned during Web Identity's development and deployment include:
- A proof of concept (PoC) is vital to the performance evaluation of applications. The WI team was aware of this, and it successfully used a PoC to understand and resolve WI's original performance problems. Conducting a PoC early in the cycle was a great benefit to the initial development and deployment of Web Identity.
- The WI team recognized that the boarding of applications could potentially be difficult, so a great deal of attention was devoted to the definition and documentation of an efficient boarding process, including addressing the funding issues for existing applications.
- When WI was first released, there were already many user ID and password systems. In order to minimize the impact on applications and users, pre-existing credentials were pre-loaded into Web Identity, allowing users to retain their original credentials without change. Although this was not always possible, it did provide a seamless transition for many users.
After its initial use across the ibm.com Web domain, WI was established as an official IBM internal development standard. This was a key step to ensuring uniform adoption of the WI tools within IBM. All development projects for external Web sites have a consistent method of assuring the identification of the users of its externally facing Web site applications.
This series of articles describes how SOA-enabled solutions have been implemented on six IBM internal initiatives to enable desired business and IT changes. All six initiatives achieved new levels of business nimbleness through faster introduction of new business capabilities and optimized business processes.
The six case study descriptions focused on identification of common business challenges and implementation patterns that were distilled from these experiences and are now being reused across IBM and client engagements. Each case study demonstrates that SOA-enabled solutions help achieve desired business flexibility by making changes to processes and business rules broader, easier, and less-expensive, even across organizational boundaries.
We thank the following colleagues for their insight and their contributions by providing experience reports for this article:
- Jim Doran (IBM Distinguished Engineer)
- Gordon Greenlee, (Enterprise Directory Lead Architect, IBM)
- Brian Olorie (Lead architect for IIP and IIPx, IBM)
- Doug Gustafson, IIPx Project Manager, IBM
- David J. Foti (CPT Program Manager, IBM)
- Steve Looney (Program Manager, Web Identity, IBM)
- Sue Petroski (Web Identity/Common Profile/Order Status On Line, IBM)
- Terry Escamilla, IBM CHQ, Enterprise On Demand BT/IT Global IT Infrastructure CoE STSM, Security and Privacy Programs, Office of the CIO Infrastructure Architect
We also thank many IBM colleagues, consultants, architects, development managers, and project managers, who developed these innovative solutions and took their time to document and share their experiences and lessons learned. There are too many of them to mention here.
- See "SOA in action inside IBM, Part 1: SOA case studies," developerWorks, August 2006, for the first two case studies in this series.
- See "SOA in action inside IBM, Part 2: SOA case studies," developerWorks, October 2006, for the case studies 3 and 4 in this series.
- Read "Information service patterns, Part 1: Data federation pattern," developerWorks, July 2006, to learn about the federation of structured information (data) with a focus on the SOA context.
- Check out "Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals" IBM Systems Journal Volume 44, Number 4, to explore the governance, economic, and enterprise challenges to SOA-based IT transformation.
- Stay current with developerWorks technical events and webcasts.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you to get there.
- Visit the SOA and Web services zone on developerWorks to learn more about SOA.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Collaborate with a community of architects and developers in the SOA and Web services discussion forums.