SAP Identity Management

2 Posts authored by: Paul Rostagno

Dear reader,

 

 

In this article I would like to discuss how to engage in an IDM project. We saw last time that IDM could be used not only as an employee profile management system (generally sourced from an HR platform) but as well to maintain and provision external users (generally sourced from company-controlled external Web sites). In fact, it could even be used to maintain various other types of objects, but we will examine this another time.

 

 

The critical mass

 

 

The challenge with this type of Enterprise program is to find a business owner that will support and sponsor the project. Indeed, your Identity Management system may eventually serve many lines of business that would need to share the investment cost. IDM comes with many adaptors to various systems and the group who is best positioned to grasp the overall future benefits of such a program is generally the IT Department. They need to make the landscape work. Interconnecting systems to make it work is primarily a technical problem, rather than a pure business problem. While reviewing and prioritizing the company road map, the business stakeholders will systematically ask “what’s in it for me?”, which is a fair interrogation. The Agile Approach fits well with an IDM implementation. Indeed, there is simply too much to tackle to go with a big-bang waterfall approach, so that tailoring stories per business use case is a pertinent methodology.

 

 

Proposal for a high-level methodology

 

 

Since there is no such thing yet to my knowledge as an Identity Management framework for the business approach, I will attempt at drafting one here, based on our internal experience at SAP Global IT. Experts could probably write a book on such a topic, and a blog may not be the best format to address the question, so I will necessarily limit my comments to a bird’s eye view here, providing general insights based on my experience. I apologize if this may frustrate people in search for a chiseled planning and detailed step-by-step operation mode. Of course, each company is free to put variations to it – or rewrite it entirely - that would make it more palatable to their own industry or business case.

 

 

Three main use cases will be addressed by your solution:

 

  • HR integration for new hires and life-cycle management
  • Master Data integration across the enterprise landscape
  • Security requirements

 

 

The first and obvious business requirement will naturally come from the need to replicate HR profiles to downstream applications and control their life-cycle. When an employee joins the company, she will require immediate access to various business systems such as a CRM or an ERD, with permissions adapted to her job title, Department or combination of both. For this, a role should be drafted at design time and then automatically granted at run time.

 

Global Risk and Compliance features may quickly surface as a derivative of this first need, in order for the company to pass the more and more exigent financial audits. Here we will strive to bundle IDM with a GRC module such as the Business Objects one.

 

An IDM architect should become the best cross-applications generalist. Hunting for pockets of redundant master data across the landscape should be part of his or her responsibility. It may be that most internal applications already gravitate around a user repository such as a corporate Active Directory or an LDAP registry, while a few others have been built in silo. The bigger the company, the more probable it is to find such examples. Reasons may be that the general repository technology is not available for a particular application. Such application may use a SQL Server database, while such other one may use an Oracle database to store their profiles etc. While the preferred choice is to gather all applications around the most relevant technology, it may not be an option for some persistent exceptions. It may even be that certain attributes can be updated from a different entry-point than HR. As an example, an employee’s photograph may be updatable in self-service via a Corporate Portal front-end, or an enterprise Address Book, and this new photograph should then be made available via an Expert Finder application, or should be seen on a blog portal. For all these cases, a central hub is necessary to avoid data discrepancy (former value still present in some applications while the updated value can be seen elsewhere). IDM will ensure a technology-agnostic propagation of profile updates to all applications.

 

To be clear for readers not familiar with the SAP Netweaver IDM as this is not obvious, this product’s reach is not limited to SAP technology connectors but can and should be used for all connection points whatever the technology: LDAP, SQL Server, Oracle, Sybase, REST APIs, Web Services, jdbc, you name it! If you find a technology where an out-of-the-box connector doesn’t exist, you can even build a client in Java for example and call it from the IDM internal provisioning system.

 

A collection of business use cases should be gathered by the architect, and used to argument in favor of a new Enterprise Architecture framework. These use cases will eventually translate into epics and stories depending on their size (a story would typically require 2 or 3 days to complete). The development team will then commonly agree on the list of granular tasks to execute in order to deliver on the stories.

 

More granular Use Cases may be defined along the following lines:

 

  • Propagate HR new employee profiles to a company Address Book or Employee Directory,
  • Provision HR employee profile creations to a CRM application, or an ERD application
  • Disable an employee profile in all corporate applications after an employee leaves the company
  • Provision an employee role assignment to a downstream application
  • Provision an external user profile creation, update or deletion to a reporting system e.g. Hana
  • Replicate external user profile updates to various Web properties such as an online store
  • Etc.

 

The more you encompass systems within the scope of your implementation, and shed some light on shadowed or neglected areas of the enterprise landscape, the easier it will be for the business to take ownership of your initial IT proposal and back it with their strong financial and steering guidance.

 

A strong determination, analytics and persuasion skills are qualities that are well sought after in this adventure…

 

Eventually, your system will reach the critical mass, in which the initial cost of the program starts outweighing the financial benefits. This critical mass can be calculated as follows:

 

Cost with IDM as the center of a start model:

 

  • Estimate the cost of the systems setup: DEV, QA, Production: this should include both servers (physical or virtual) and software (SAP Netweaver IDM, SQL Server) as well as ramp-up time (e.g. 50 PD x number of developers) for the development team to learn and become highly efficient with the new technology;
  • Estimate the integration costs: interface between HR and your new system, between your system and any downstream system you can foresee. This is your resources cost that you may want to gage with your traditional PM measuring stick, e.g. 50-100 PD per interface including development, unit testing, PM, QA phase and deployment depending on your IT local challenges and technology.

 

Cost without IDM (“chaos model”), with redundant integration points:

 

 

  • Here the integration costs will represent point to point interfaces between your systems, e.g. HR to CRM, HR to ERP, HR to Corporate Portal, Corporate Portal to Active Directory, Corporate Portal to External Web Site etc. Quicker than you think, you will come to regret the lack of structure of such architecture.

 

Your ROI demonstration to the business will derive from the calculation of the critical mass in terms of number of systems gravitating around your Identity Management hub. At some point, the benefit of building a clean star-like architecture with single branches connecting each satellite system to the IDM center will become financially obvious.

 

Indeed, for each added system in a star-like architecture, you only need to build one branch-like interface, between the new satellite system and the IDM center, while in a chaos-like architecture you may need to build several interfaces out of any single new system, especially if this new system is an entry point for master data updates: connection to CRM, connection to HR, connection to Address Book, etc.

 

At this time, your initial architectural choices will have covered the initial investment of building an IDM landscape and ramping up your development team, and the margin will start fueling your enterprise landscape growth engine: instead of building 2 or 3 interfaces right away for your new marginal system, you will only need 1 interface to IDM and control the flow of attributes and rows per target system directly from the IDM Identity Center. You will do the math: 2 or 3 times the 50-100 PD versus just one time 50-100 PD.

 

At this point the business will be won to your architecture choice!

 

The Security requirements will only consolidate your motivations for a new IDM architecture: your company may be subject to audits during which you want to demonstrate who has access to which system and with which privilege. The business rules that you will develop in your new IDM system will save you of sleepless nights trying to identify loopholes in your security model.

 

 

The endurance run of the IDM architect

 

 

As we can see from the above, Identity Management is an Enterprise Architecture topic, resulting in structural changes across the landscape.

 

While an Agile approach is tailored to provide immediate benefit right from iteration 1, it may take quite a few iterations to build the critical mass described above.

 

Before reaching the critical mass, your program will be labeled as an “IT project”, with all the pejorative connotation that traditionally comes with it. You will have to fight searching for business support for your project in these early days. Your struggle will be exacerbated by the fact that you will serve several lines of business at once, with no central owner. This is why this type of approach must come from the top, namely the CIO. Only the CIO can give the initial impulse that will help you make the right architectural choices when business stakeholders may remain lukewarm. After the critical mass has been reached,
business owners will come from all directions to claim full ownership of the new engine, reaping the rewards of the initial choice. At this time you will know that you won the battle, for the sake of the company.

 

I hope you will find some take-away price in this series of shared experiences on the Identity Management topic. Or maybe you will be amused by the discovery and contemplation of the wanderings and challenges of the job. Next time, we may talk about the security model and “entry types”. As always, your feedback is most welcome!

 

Kind regards,

Paul

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

Actions

Filter Blog

By author:
By date:
By tag: