The answer is zero. A unique identifier adds nothing to any logical problem we have with our data. Let’s see why this is true. I have two sets of data from different systems, which represent information or attributes about a real world user. Those data elements are indistinguishable from each other. Perhaps they are first name, last name, city and state. They are identical as far as I can tell. If I add a unique identifier do I know anything more about them? I just know they are no longer identical and yet they may be in the real world the same person. By adding a unique identifier I may have made a distinction, which is false. It’s impact will only be deleterious never beneficial. The unique identifier becomes ornamental. Metaphorically it is like placing a medallion around the neck of the famous twins and still not knowing if it’s Tweedledee or Tweedledum. At least in this case I could re-name them to something like Dee and Notdee, which would be meaningful to an observer. However, in the foregoing example, we are dealing already with a representation of an entity and it adds nothing. Now let’s add several more attributes, for example, title and department. If I can now distinguish easily whether they are the same person or not I have accomplished my goal and I still have not added a unique identifier. The smallest subset of elements that distinguishes one set from another is a suitable key if the data is in a database and I still haven’t added a unique identifier. So then how are unique identifier’s useful? They are useful within a context in which we are programmatically creating many closely similar but not identical objects whose existence is ephemeral. When we are combining data from many different contexts, they solve nothing; they are just another attribute.
The landscape document from SAP that explains how to export from HCM to VDS to Identity Center has sections that are less than clear so I thought I would list common issues that have caused problems in the past. First the architecture. The way the export works is as follows:
- A report is run in SAP HCM which extracts the necessary data formated as LDAP data.
- SAP connects to the VDS and pushes the data.
- VDS connects to the Identity Center information store and uploads the data.
A couple common problems I have seen.
- The field names inside SAP are misnamed or the export names to LDAP are.
- The LDAP libraries in SAP Basis are not installed.
- VDS Template: The one you want to use is this one “HR Export to IdM Identity Center.xml” this one will not work “HCM LDAP EXTRACT for IDM.xml”
- Bad credentials or passwords (of course)
- VDS Tree for HCM is broken in some way. If in doubt recreate your setting from the template.
- First determine where you are broken.
- Turn on verbose logging at VDS and see if HCM is even connecting.
- If you are connecting to VDS but no data is reaching the Identity Store then check the LDAP extract for misspellings. One error in your path and the whole thing breaks.
- If VDS shows database errors then check the error logs in the identity center for problems with the task configuration
Finally, because HCM does not support event triggers — which can be tricky — I usually filter at HCM LDAP report for the data I want. In most cases a nightly run is sufficient. SAP recommends a full upload every time but this is not practical for large numbers of employees.
(This post was written by Matt Pollicove)
One thing I’ve noticed when talking to people about Identity Management projects involves how to determine the project’s overall scope. “How do I scope this?” they will say to me. Now that’s kind of tough to answer right off the cuff, especially when considering Pollicove’s Law of Provisioning which basically says there’s no guarantee that companies that are in the same vertical will work the same way.
However, I think there are some best practices that can be worked with when considering implementing an Identity Management solution:
1. Make sure you have executive sponsorship. C-level support is going to be important in balancing the needs of your stakeholders and their budget dollars.
2. Make sure you have a good plan of what you want your Identity Management solution to cover. An essential part of this is conducting a thorough assessment. Document everything, diagram existing processes, then take them apart and put them back together the way they should be, then do it again. This should be done with a combination of internal and external sources. Internal resources know how current systems are configured and interact. External resources will offer an impartial assessment of how these systems can interact more efficiently. External resources will also be helpful in determining which Identity Management products will work best in your infrastructure.
3. When building your plan, know where you’re starting from. What will be used as your authoritative store? How will it be built?
4. Where are you going to? What will you provision to? What will you control access to?
5. How are you going from 2 to 3? How will you engineer your changes? What will the phases of your project consist of?
Item 4 is probably the most important part of the process. Many a project has suffered due to overreaching phase objectives. Carefully define what you want to achieve in each phase.
Data cleansing and analysis is almost always your first phase. If you don’t have clean data, you won’t have a clean project. Future phases can deal with:
· Creating an Authoritative Store
· Provisioning to essential systems
· Password management
· Role management
· Provisioning to secondary systems
So the big question is what order does this happen in? How long will it take? I always suggest attacking “low hanging fruit” first by attacking the easiest objectives that will show the biggest net gain? As a part of number 1 above, think about solving automation needs, compliance needs, addressing password management request costs to the helpdesk?
How long will it take? As long as it has to. This is going to be a major project that will affect many systems and departments. Take it slow and easy. Test it thoroughly and make sure there’s a good knowledge management/training initiative to let your users know what happening and how everyone will benefit. It’s never good if your users equate an Identity Management initiative with a foul tasting medicine. This includes your stakeholders.
Password synchronization has been a requirement since the early days. There is a lot of fuzz going on in the industry surrounding this ‘feature’, but let’s face it – It comes down to a simple question: How convenient do you want your Business Support Solution to be? Do you want it idiot proof or secure? There is this widely respected and agreed statement that only a one-time token is safe enough to protect your holy data from unwanted access, but when it comes to passwords more than one of them is too much hassle to deal with. Sure, there is products out there that will give you the technology to synchronize everything back and fourth, but is this in accordance with CIA (Confidentiality, Integrity and Availability – not the agency)? I don’t think so. Let’s be honest to ourselves: It is always a balance between what the business wants IS/IT to deliver and what make sense from a infrastructure point of view. But fortunately there is SSO and our beloved child NW IdM 7 that will solve some of these problem.
I saw an interesting article that discusses the concept of Identity Management 2.0.
The article starts with a good recap of current, or Identity Management 1.0 capabilities, that we are all familiar with, access management, LDAP, Provisioning, etc.
Where the article gets really interesting, of course is when the Author delves into what he considers to be the revolution of Identity Management. As the article states:
The core platform of Identity Management 1.0 capabilities such as authentication, authorization, user provisioning, password management and the like has provided a base for improving security and automating manual processes to drive down operational costs. Identity Management 2.0 extends the core platform to offer stronger forms of authentication, risk-based authorization and fine-grained entitlements, user provisioning based on roles and relationships, as well as the ability to virtualize identities, all in an effort to address the next generation of requirements and threats.
What, to me, is even more interesting is that an old IdM technology, Virtual Directory, is considered to be a core component of IdM 2.0. Dubbed “Identity Virtualization,” the article likes using this technology for creating customized user repositories for applications. Maybe the oft-quoted “Year of the Virtual Directory” is finally coming to pass.
It should be interesting to see how this concept matures over the next 12-18 months, particularly as we’re going into what many consider to be tight times in the IT world.
For those of you looking to download a copy of Strategies for Creating an Authoritative Store, it is now available from the SECUDE Global Consulting website. The paper was initially released through Business Trends Quarterly.
The paper is intended to be a discussion of creating an Authoritative Store for use in an Identity Management Infrastructure. It provides a good starting point for those considering implementing or revising their IdM landscape.
In working with Virtual Directory Server with the latest patches and HCM this past week, I ran into a fairly annoying problem. In order to recieve data from SAP HCM you run a simple wizard, select the template and then save all your choices as an xml file. Loading this file defines your server. What I noticed with the server is once it is in place if you make any changes with the GUI such as changing a username or password, adding a feature and removing it, is that it breaks the configuration everytime so either I am not doing something correctly or there is a big bug in the GUI. Making the same changes directly in the xml file with notepad does not break the configuration. When I get more time I will dig a little deeper.