Content

Identity Management Case Example

A large food and general merchandise wholesaler in the United States had a strategic vision based on strengthening its relationships with the market’s largest retailers, and increasing its vertical penetration through the acquisition of niche channel wholesalers.

The company was relying upon the added business flexibility provided by their SAP implementation and extending their existing investment in legacy technology to support this vision. Integration of the legacy technology, however, had become a barrier to their success, due to its security management inefficiencies and administration risk.

The company was struggling with maintaining a secure IT architecture compliant with government laws and corporate business control objectives. Their existing security architecture was based on the coordination and integration of disparate application-based security systems. Each of the applications was designed with its own user identity, authentication and authorization capabilities that resulted in their security management becoming overly complex, labor-intensive and error-prone.

The company was seeking to transition to a shared-service identity management architecture, consisting of directory and security services that make identity, security and policy management reusable resources across all applications. At the center of this vision was their desire to extend their investment in their SAP R/3 Human Resources module and use it as the authoritative source for their identity management solution.

The company had two key objectives.

The short-term objective was to implement a security solution whereby authorization for access to the warehouse management system would be centrally defined, managed and controlled, based on predefined job roles. The solution had to automatically add, change or delete a user's access in all warehouse systems within the company's numerous distribution centers located throughout the United States.

The long-term goal was to design an identity management solution that would create an efficient and reliable process for ultimately administering all user access needs for all level-one applications (to include TCI, Manugistics, SAP, MS Exchange, and WebSphere MQ) and operating systems (to include OS/390, AS/400, NT and AIX) at the company. The company also was introducing a new internet architecture and looking to increase their web commerce capabilities. The identity management solution had to incorporate a web single sign-on solution (using IBM Tivoli Access Manager) that will establish a common web authentication, identity control and authorization structure.

Creating the solution

A four-week strategy session produced requirements and an implementation plan to achieve the short- and long-term objectives. The high level design consisted of utilizing SAP R/3 HR as the authoritative source for the company's employee identities. Events (hire, change, termination) would be provisioned from SAP to an identity repository consisting of Novell eDirectory.

A 'role based access controls (RBAC)' model would be developed based upon employee attributes available within SAP R/3 HR (job codes and positions), and utilized to provision employee actions (add, change, disable) to downstream applications. The provisioning of employee information from SAP R/3 HR to the identity repository and down to a warehouse management application would be enabled using Novell DirXML software/technology.

The final component of the solution would be establishing IBM's Tivoli Access Manager as the single control point for web based authentication to secure all internet and intranet-based traffic/access. Tivoli Access Manager would be configured to use the identity repository as the authentication source for web-based applications and users.

A 90-day implementation plan was developed that broke the project down into four steps:

  • Establishing SAP as the employee authoritative source
  • Implementing the identity repository
  • Provision to the warehouse management application
  • Implementing web single sign-on for selected applications

The first deliverable in this step was an 'identity model.' The process used to develop this model consisted of an analysis of the SAP HR environment and business processes, as well as the applications to be provisioned downstream and protected by the web single sign-on solution. This analysis required not only a review of the technical needs of the applications but also of the underlying business processes supporting the technology (HR and downstream applications). This was done to ensure that any data quality demands placed on the model could be supported.

The next step was to enable the clients SAP R/3 Human Resource module to share information between SAP and Novell eDirectory. SAP requires the use of application link enabling (ALE) functionality and an SAP-validated interface method (IDOC processing) to share information. ALE uses SAP intermediate document (IDOC) capabilities to pass information across systems.

Synchronizing between systems

It was determined that the identity repository would require a flat tree structure. The initial scope of the identity management project was to synchronize 'employee identity' attributes from the SAP R/3 HR module to an identity repository 'Company_IM tree.' This was achieved utilizing a technology solution from Novell called DirXML. DirXML is an event-driven utility that provides flexible synchronization between disparate systems so that enterprise data can be kept up to date with minimal maintenance costs. DirXML was used to synchronize employee identity information between SAP R/3 HR, eDirectory and the warehouse management application.

Since the applications had different ways of representing data elements, DirXML was used to match the 'object classes' (accounts or records) and 'attributes' (fields) between the different applications. By doing this 'schema mapping,' the underlying applications did not need to be modified to match eDirectory. Each application was enabled with a DirXML driver that mapped their object classes and attributes to allow the DirXML configuration to be based on eDirectory attributes.

Additionally, some applications required fields to be filled in before a user account could be created. By identifying these required attributes, DirXML was used to enforce the business processes by 'vetoing' the creation of an account until all required attributes had values. Applications also had existing employee accounts where a method to match objects between the systems had to be created. We achieved this through a process known as 'object mapping' that allowed existing objects to be matched to existing or newly created eDirectory objects as long as unique matching criteria could be determined.

Finally, different applications did not represent data in the same format or method. This was overcome through the use of data transformation techniques that can manipulate data from one system to the next into the proper format. This can be as simple as translating a full name into three attributes (given name, middle initial, last name) or as complex as applying an external process to a series of attributes.

DirXML was also used to provision the necessary accounts to the warehouse management application. This was achieved by the execution of a data mapping exercise that identified all the necessary fields required by the warehouse management application. Each field was then reviewed to determine if it would be populated directly from an identity repository attribute, derived from an identity repository attribute or created by the DirXML functionality based upon predefined rules.

Implementing web single sign-on

The first step of this phase was to analyze the usage patterns. This proved difficult in that all usage was estimated while there was little or no current activity. We developed a number of architectural assumptions for this portion of the project.

  • Estimated number of users would be 35,000
  • Average web single sign-on user LDAP footprint is estimated at 20Kb of storage per user
  • Average size of authenticated authorization request is estimated at 5Kb
  • LDAP replication schedule and propagation queue sizing estimates have concluded that replication will be done in batch and for 35,000 LDAP users the size of the propagation queue and its effect on the master LDAP server performance is of minimal concern.

IBM Tivoli Access Manager includes a high performance, multi-threaded web reverse proxy that applies fine-grained security policy to the protected web object space. In this configuration, IBM Tivoli Access Manager delivered single sign-on to the company's IBM Websphere portal and underlying web applications. Out of the box however, the Tivoli Access Manager did not provide for native integration with eDirectory for user authentication (although the latest version 4.1 does provide out-of-the-box integration for Novell eDirectory).

To achieve this we utilized the cross domain authentication service (CDAS) functionality of Tivoli Access Manager, a tool for federating authentication requests to directories and user repositories. In this configuration, users were authenticated in Tivoli Access Manager to the Novell eDirectory IM tree. Required attributes are returned from eDirectory to the CDAS API that then returns these attributes to Tivoli Access Manager where access decisions are made.

Lessons learned

The project from start to finish lasted eight months and established a new internet-enabled security architecture based upon the existence of identity driven enterprise roles. These roles enabled a consistent definition of a user's business purpose for access to company resources and more timely and efficient administration. The cost savings goal that is now being targeted is to reduce their helpdesk support calls by completing the standardization of user IDs and passwords across the architecture. The company estimates a 90 percent reduction from their historical 5,000-a-year password reset call population.

The project itself reinforced to management the need to identify key stakeholders early in the project. Achieving this level of integration across a security architecture is disruptive; frequent and meaningful communication with business process owners was crucial to identifying and resolving process/technology conflicts throughout the project.

Additionally, management realized that implementing an identity-based security architecture requires extensive enterprise requirement definitions and sufficient full-time resources to ensure sustainability.

The solution provided the company with key value statements, which focused on corporate goal and initiatives:

  • Unified end-user experience – reduced the number of user IDs and passwords making it easier for the employees to gain access through standardization and centralization
  • Cost reduction – web single sign-on with password management reduced helpdesk calls and improved employee productivity
  • Enterprise standardization – established enterprise security requirements/standards for future e-business application design and integration

Creating an identity-based security architecture allowed the company to easily migrate from a decentralized security architecture to a centralized architecture based on business processes. The end result was a robust and flexible security architecture to handle acquisitions and the migration towards a pure web-based application architecture.

Jim Burns is a principal with Deloitte & Touche (www.deloitte.com).

 

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.