Creating Secure Methods of Accessing Identity Store Data in NetWeaver IDM

At its core, NetWeaver Identity Management’s Identity Center is a metadirectory based application. This means that information is taken from various sources (e.g., HCM, AD and other feeds) and then brought back into the IDM database to create a single authoritative store. By bringing all of the data in the form of attributes, into a single place, data access is easier and more efficient. 

      This being said, not all attributes are created equal and should be easily accessible, thus necessitating some level of “protection”. These attributes are defined as personal or significant to the owner of the Identity, and do not need to be readily shared, but might be needed by organizational personnel and thus should be accessible via a tool such as IDM.

What kinds of data might this be? That’s kind of hard to pin down. Each organization has its own determining factors on what data should be protected based on Compliance, Legal, Cultural and other factors. Should all this data be stored in the Identity Management solution? That’s tough to say, all I know is that if it’s required in the project, we discuss the pros and cons, come to a consensus and move forward.

As we move forward it is necessary to develop a methodology to properly protect the data and plan for its use in a secure way. In NetWeaver IDM, I have come up with the following methodology:

1. All protected data is stored in an encrypted format. By default, IDM uses 3DES as its reversible encryption. (MD5 and SHA-1 are used for one-way or hashed encryption
2. Access to protected data via the IDM Web UI is done using ROLE based tasks in the Web UI.
3. To access the data, a separate task must be used to log their access of the protected data, using the Access User Info task. This task will decode the relevant secure data to clear text attributes. An additional task in this workflow will clear the clear text attributes after a specific time period has expired.
4. Once this has been done, we can then access the Web UI task that contains the sensitive information. In this example, a task that allows Administrators to Edit user data. Presumably some protected data can be viewed from this task.
5. Once the task with the secure data has been submitted the attributes holding the clear text data will be cleared. The task in step 3 above will still execute as a double check.

Now why do it this way you might ask? There are two reasons:

• There is an additional audit entry showing that the user requested “elevated access”
• NW IDM does not allow for “on the fly” decryption of attributes, citing it as a security breach.

I’ll tell you, at first I really did not like SAP’s reasoning on this, but the more I thought about it, it made sense, given that now the person requiring access must log their request for elevated viewing rights providing for more detail about what is happening. This way the Service Desk user can still just examine the user’s record and the secured attributes just appear blank. Is there a right or wrong way to do this? 

Does this solution break “best practices” or define them? Again, I’m not 100% sure. What I do know is that this methodology offers the most pragmatic compromise and offers the smallest “data access window” and as long as the decisions and details are documented, we should be good to go.  

Thoughts?