Skip to Content
Author's profile photo Ali Ajdari

Enterprise Group Management using SAP Netweaver Identity Management 7.2

In this blog I would like to provide an overview of how IdM 7.2 has enabled SAP to manage its massive amount of Distribution Lists which are part of day to day business operation. While some technical aspects are covered, I will focus mostly on the business value that IdM 7.2 into the solution.


SAP internal Distribution Lists (DLs) were previously maintained using a very old implementation of R/3 portal(a.k.a SAPNet). This system introduced a risk to business operation as it was too old and the hardware/software stack was already at the end of their life cycle. As a result, Global IT decided to define a project for the migration the processes and data over to other target platforms and retire SAPNet completely.

As the delivery manager and head of IdM competency center in one of the IT application teams(i.e. Social Collaboration Platform), I had the responsibility of providing a retirement path for SAPNet, manage the planning and oversee the execution of all the work streams within the scope of the retirement project. One of the work streams was indeed Group Management which required us to migrate all legacy DL data as well as relevant processes to another system. SAP Netweaver Identity Management 7.2 was confidently chosen as the product for DL management.

Pre-Migration Status

In large companies such as SAP email communication is key. As such, timely creation and availability of Distribution Lists are always critical to the success of business. Aside from the initial creation of DLs, the ongoing changes to DL hierarchies as well as user memberships, involve a lot of effort and overhead costs if the process were to be dependent solely on an IT support function within the organization.

At SAP, there are also some special type of DLs which are used for security purposes (rather than pure communication). These DLs are built automatically based on a controlling attribute (i.e. cost center) with some complex hierarchy. The DLs are then used by internal applications to enforce authorization.

In order to overcome the challenge and complexity, SAP had implemented an integrated solution comprised of the following components many years ago:

  • An application with an end-users interface for self-serve DL management(SAPNet).
  • One or more source systems to build DL memberships automatically in the back-end based on some business-centric criteria and replicate the DLs to the main repository.  An example of the criteria would be “A DL which includes all sales managers”.
  • A process to replicate all creation/updates/deletion of DLs from the main repository into corporate Active Directory.
  • A set of APIs to expose DL data to other internal systems that would need to either read from or write DLs into the repository(i.e. RFC enabled Function Modules in SAPNet).

All of processes had to be re-implemented based on IdM 7.2 and all legacy data migrated to IdM 7.2 Identity Store before those process could be retired on the old SAPNet system. The analysis and planning to establish the correct sequence for both process and data migration was enormously complex due to various reasons such as quality of legacy data(i.e. hierarchies with loops etc), limited documentation of the old processes(developed more than 10 years ago), etc. In this article we will focus on the solution itself rather migration activities.

IdM 7.2 Takes Over

Now the fun part begins! That is to design an architecture which can not only satisfy the current requirements of our project but also lay a solid foundation for future growth. To achieve this, project team decided to utilize an internal cloud platform that offers Continues Delivery and DevOps.

This decision posed a huge challenge for the project as we had to work within the boundaries of product features as well as budget & timeline but the effort worth it. At the end, we were able to automate server setup and deployment of IdM Identity Center, Run time and Database host. What a pleasure!

A completely new landscape (i.e. development environment) could be built from scratch with the most recent code/configuration in less just a few hours! Although, I have to point out that the server setup and deployment to Netweaver UI could not be automated due to time constraints.

Let’s review the architecture and examine the role of IdM 7.2 in the enterprise level distribution list management solution:


Some business processes rely heavily on DLs that are generated in SAP business systems based on some criteria (as opposed to creation or updates by end-users). Those DLs need to be replicated to AD before they are usable. To achieve this and in order to achieve a federated approach for DL provisioning to AD, IdM 7.2 sits in between the business systems and AD. Two Virtual Directory Servers have been implemented for this purpose:


  • The first one is generic one which enables any application within the corporate network to connect to IdM and create or update DLs. This VDS is fully scalable and can handle multiple clients in parallel while enforcing necessary logic to maintain data ownership per client. Currently, SAP’s HR as well as a reporting system are connected to this VDS and pushe their DLs to IdM several times a day. DL memberships are determined according to some criteria before the updates are replicated to IdM.

  • The second VDS is very specific and implemented exclusively for another instance of IdM (called IT IdM) which is in charge of user/role provisioning to SAP Business systems. The IT IdM pushes pre-defined DLs used for authorization purposes to this VDS multiple times a day. The same VDS is also receiving user data updates from the IT IdM system.

  • As I mentioned in the beginning of this blog, a self-serve interface for DL management is required to avoid dependencies on an IT support function for every single change.  Our self-serve solution is a Web UI application that is fully integrated with IdM. The integration between IdM and WebUI is bi-directional:

    • An in-bound connection has been implanted using a VDS in which the Web UI pushes all end-user updates to IdM and from there to AD.

    • As for the out-bound integration, the Web UI is exposing some RESTful APIs. These APIs are called by IdM provisioning to replicate any updates from other source systems to the Web UI. This way all the back-end DLs are also visible to end-users. However, they are all displayed in read-only mode as the owner of such DLs are the upstream systems (and not the end-users).

IdM 7.2 Netweaver UI is used as an administration interface. Here some  custom UI tasks have been implemented to cover the necessary functionalities for our support 1st and 2nd level support colleagues. The custom tasks enable to check on the replication status of DLs( both inbound and outbound) as well as enhanced DL maintenance functionality(compared to Web UI functionality available to end-users).

A set of Java-based RESTful APIs have been developed and hosted on NW host. These APIs enable other applications to query IdM DB, search for DLs and read DL attributes. A wide range of parameters and options are available to suit the needs of the client applications.

The most critical and complex integration is the outbound connection from IdM to the corporate Active Directory. Although IdM 7.2 offers a connector to AD out-of-the-box, due to some specific data replication requirements, we had to develop a custom LDAP connector. This connector consists of a set of Java components , IdM jobs, and custom DB tables.  A queuing mechanism has been implemented to ensure all updates are processed in order and can be re-pushed to AD in case connectivity is lost.

The IdM DB utilizes SQL Server 2008 which was originally hosted on a cloud VM.  Both the host and DB used to be built & deployed leveraging DevOps Chef scripts. However, overtime the VM reached its I/O limits due to high volume of updates and consequently the db performance degraded. After reviewing different options, we came to a conclusion that a physical host would be a better option long term and moved ahead with the change.

Each of the integrations has one of more corresponding jobs that run according to their schedule. Some require more frequent executions that others. Additionally, there are some stand-alone jobs that cover other areas of functionalities such as DL generation based on cost center controlling attribute in IdM.

The summary above is of course a simplified view of the architecture but I hope it can give you an idea of how IdM 7.2 supports business processes related to DL management at SAP.

Now let’s look at some statistics.

The Stats

It is always useful and interesting to gather some statistics and better understand the usefulness of a solution. Below are some figures I have gathered recently:


* Note that there are many DLs with a nested hierarchy whose member count is not included in this table.

The chart below shows the size of the AD connector queue size over a 24 hour period (Dec. 3rd, 2013):


The Bottom Line

The implementation of SAP IdM 7.2 for Distribution List management did not come easy. There were many challenges along the way from the early stages when a blueprint was produced all the way to the implementation, go-live and the support afterward. The effort, however, was worth it as critical business data and processes were migrated successfully to IdM from a very old legacy system. SAP IdM 7.2 has been running since late Q1 earlier this year and continues to be the backbone of DL management for years to come. The implementation has been a true example of “SAP Runs SAP” program.

I hope you have found this blog useful. Please feel free to post your questions or comments and I will be sure to address them accordingly.

Ali Ajdari

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Matt Pollicove
      Matt Pollicove

      Always nice to see SAP drinking its own Kool-Aid!  Definite evidence that SAP IDM works in large complex environments!!!

      Author's profile photo Ali Ajdari
      Ali Ajdari
      Blog Post Author

      Thanks Matt. For sure, SAP IDM has stood up to the challenge!

      Author's profile photo Former Member
      Former Member

      This is a nice tech demonstration but from my point of view you use SAP NW IDM as a super administration tool and  not as an IDM tool. You are managing (creation) Authorization Objects in the target system i.e. in case of AD creating and deleting groups.

      My IDM pattern would be: for the application authorization objects the application is in charge and not IDM. IDM has to provision the users into the applications authorization structure / objects and therefore (as far as I have understood) the SAP NW IDM architecture uses privileges. From my point of view the right pattern would be:

      - Create the authorization objects (i.e.) groups despite of DL or security groups within the application, AD does have a LDAP interface, you can also buy or make some webservice stuff for it.

      - Represent each group as a privilege in IDM.

      - If a user has to become member of a DL assign the privilege.

      I see your point to a use an existing tool with more or less nice interfaces to target systems as general purpose administration all stuff thing but where do you stop?

      Why not create SAP Activity Groups using IDM? Why not create Lotus Notes Groups using IDM? Why not create all Groups in AD for any application (Sharepoint, Lync, Exchange, custom applications).

      Such technical driven IDM which demonstrates anything technical possible will become a night mare in maintaing and extending the solution.

      Again nice technical insight what can be done with IDM but from an IDM perspective it's a strange design.

      Author's profile photo Ilinca Garabedeanu
      Ilinca Garabedeanu

      Hi Thomas

      As the technical lead of the project I can provide some technical details:

      • WEB UI application is the main application that allows business users to create group objects as well as assigning memberships (and we do limit only to DL based on existent business requirements).
      • There are several other existing backend processes that also creates / updates DL groups.
      • WEB UI application, as well as backend processes have the capability to perform bullk memberships upload (users as well as groups; nested groups are allowed).
      • Main business function of these groups is: Distribution List for Outlook.

      Therefore, instead of building several point-to-point integrations with AD (which is a critical component of our corporate landscape) we have decided to use SAP IDM as a single entry point to Corporate AD using its provisioning capabilities.

      What triggers the provisioning event in our case:

      Due to the fact that groups are mainly used as Distribution List (not really authorization objects in AD), as well the bulk memberhsip upload feature and nested groups, we have decided to use only the Master / System privilege concept and the group change attribute to trigger the actual provisoning to target.

      Hope this clarifies little bit on technical side how we are using the SAP IDM.

      If you have any futher technical questions feel free to post them here.

      Author's profile photo Ali Ajdari
      Ali Ajdari
      Blog Post Author

      Thank you Thomas for sharing your thoughts. I hope Ilinca's comments clarify the reasoning behind the design. Please let us know if you have further questions.