Dear reader,
My name is Paul Rostagno. I am a lead architect within SAP Global IT, working on Identity Management solutions. This is the first article of a series that I will author on Identity Management.
Today I would like to address the question of where to build an Identity Management solution within the enterprise landscape.
Most of us are thinking of Identity Management as a solution to address the recurrent issues of employee record provisioning. I must admit that this is at least partly due to the way vendors do position their products to customers. In this context, an employee record is created within an HR system upon hiring the person, and this triggers a push to the Identity Management system. The customer is also advised to bundle the Identity Management solution with a Governance, Risk and Compliance (GRC) tool to help assess the risk of role assignments and manage corresponding workflows. This classic approach is very pertinent and sound.
Nevertheless, there is more to Identity Management than this classic approach. Indeed, Identity Management can be used to manage any type of master data, meaning stable data as opposed to transactional data. For those already familiar to the SAP Netweaver IDM, out-of-the-box or even custom entry-types are the way to represent those master data concepts. If employee records naturally fall into this category, external users are another large group of objects maintained by companies that have an online presence. At SAP, we do have a large collection of Web properties. The SAP Community Network (SCN) Web site is one of them. We do also have a Business Center site for ByDesign customers, a sap.com Web site for advertising our offer, a Service Market Place Web site for customer users, a SAP Store eCommerce site for ByDesign customers and prospects etc. All in all, more than 4 million external users and growing have self-registered to one or more of these Web sites. The corresponding user records generally have a much smaller footprint than the internal employees. The reason is that a self-registraton process must be as less invasive as possible for a company to grow its marketing user base. An email address and a password is the bare minimum, then users can enrich their profile via a profile upgrade procedure or form if they want more. Indeed, to allow a person to do business on-behalf of a company within one of our Web properties, we will need more information such as the first and last name, a phone number, the company address attributes etc.
For employees, a company will typically store dozens if not hundreds of attributes as this information is easier to obtain: a new hire will voluntarily provide all sorts of information if they want the job, which is normal.
Conclusion: a large company typically maintains two sub-populations of users:
- The employees and potentially internal consultants;
- The external users, self-registering or being registered on-behalf, via their external Web properties
Often times, with the enterprise landscape maturity growing, the company is faced with the challenge of integration flows of external users' records, just as it did for employees:
- 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.
The Identity Management system should be positioned as close as possible to the referential system of the master data you are trying to administer.
- 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.
The SAP implementation
Within the SAP landscape, we have implemented two main instances of Identity Management:
- 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
