Positioning of an Identity Management solution within the enterprise landscape

• The employees and potentially internal consultants;
• The external users, self-registering or being registered on-behalf, via their external Web properties

• Employee records must be provisioned to a variety of business backend systems, such as an HR system, an ERP, a CRM, an internal Ticketing System and a Corporate Portal;
• External user records generally originate in an externally faced Web site, they must be pushed to various other systems, such as a Marketing emailer site, a CRM backend system, a reporting data warehouse, a cloud solution etc.

• If you are only interested in managing employee records, it should be locate as close as possible to your HR system. Typically, it would be your highest security zone in your network.
• If you are interested in managing external user records, your Identity Management system should be close to the Web properties that expose the corresponding registration forms. It may be within the DMZ if you intend to use the Identity Provider (IdP) that comes with SAP Netweaver Identity Management for example. You may also decide to use the SAP ID IdP solution for the cloud, within your DMZ, while IDM is still located within your corporate network, to give you more control on internal Java portals for example. In both cases, you may decide implementing a cascading model between two IDMs. This is in fact what we have implemented at SAP, as discussed in the next section.

• An internal IDM that we call our “IT IDM”, integrated with both HR as a source and the BusinessObjects GRC as a compliant tool;
• A external IDM that we call our “SAP IDM”, still within our corporate network, pushing and pulling relevant records to/from a SAP ID instance that serves as our Central Identity Provider within our DMZ.
  • This SAP IDM receives data from the IT IDM (cascading model for employee/internal consultant records that need to be provisioned to the front-end
  • It also receives data from the SAP ID for external users registering online
  • It serves as a hub between internal backend systems and external front-end systems

While the IT IDM only deals with our 55,000 employees, but with an extended attribute footprint (hundreds of fields), the SAP IDM manages 4+ million users – including the external presence of employees – but with a much smaller foot-print in terms of attributes.

Often times a prospect company would want to know how far we can push the metrics in terms of user records. Here you go: while our SAP IDM does maintain 4+ million user records, we placed an instance of SAP ID service within our DMZ, as the central SAP Identity Provider. It identifies most of the traffic for SAP (some sites are still using local authentication but their number is shrinking fast as our SAP ID keeps ramping up). This should show our faith and trust in our architectural choices: if this SAP ID (properly clustered) ever goes down, SAP wouldn’t have anymore presence on the Web, which would have a major impact on our company. As an example, SCN and sap.com are some of the most visited sites with millions of users registered. If our SAP IDM goes down, many business functions impacting external users would simply not work anymore (e.g. ByDesign SAP Store provisioning). If our IT IDM goes down, our internal SAP ABAP business systems would become out-of-synch from a user/role provisioning viewpoint.

Next time we may discuss how SAP Netweaver Identity Management can help address some of the enterprise landscape challenges.

I hope you will find some interest in this series : )

Kind regards,

Paul