Identity Management Tips, Thoughts and Opinions

Matthew Pollicove

Subscribe to Matthew Pollicove : eMailAlertsEmail Alerts
Get Matthew Pollicove via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Sarbanes Oxley on Ulitzer

Blog Feed Post

Creating Secure Methods of Accessing Identity Store Data in NetWeaver IDM

At its core,NetWeaver Identity Management’s Identity Center is a metadirectory basedapplication. This means that informationis taken from various sources (e.g., HCM, AD and other feeds) and then broughtback into the IDM database to create a single authoritative store. By bringingall of the data in the form of attributes, into a single place, data access iseasier and more efficient. 

      This being said, not all attributes are created equal andshould be easily accessible, thus necessitating some level of “protection”. Theseattributes 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 organizationalpersonnel and thus should be accessible via a tool such as IDM.

What kinds of data might this be? That’s kind of hard to pindown. Each organization has its own determining factors on what data should beprotected based on Compliance, Legal, Cultural and other factors. Should allthis 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 andcons, come to a consensus and move forward.

As we move forward it is necessary to develop a methodologyto properly protect the data and plan for its use in a secure way. In NetWeaverIDM, I have come up with the following methodology:
  1. All protected data is stored in an encryptedformat. By default, IDM uses 3DES as its reversible encryption. (MD5 and SHA-1are used for one-way or hashed encryption
  2. Access to protected data via the IDM Web UI isdone using ROLE based tasks in the Web UI.
  3. To access the data, a separatetask must be used to log their access of the protected data, using the AccessUser Info task. This task will decode the relevant secure data to clear textattributes. An additional task in this workflow will clear the clear textattributes after a specific time period has expired.
  4. Once this has been done, we canthen access the Web UI task that contains the sensitive information. In thisexample, a task that allows Administrators to Edit user data. Presumably someprotected data can be viewed from this task.
  5. Once the task with the secure data has beensubmitted the attributes holding the clear text data will be cleared. The taskin 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 thatthe 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’sreasoning on this, but the more I thought about it, it made sense, given thatnow the person requiring access must log their request for elevated viewingrights providing for more detail about what is happening. This way the ServiceDesk user can still just examine the user’s record and the secured attributesjust appear blank. Is there a right or wrong way to do this? 

Does this solutionbreak “best practices” or define them? Again, I’m not 100% sure. What I do knowis that this methodology offers the most pragmatic compromise and offers thesmallest “data access window” and as long as the decisions and details aredocumented, we should be good to go.  


Read the original blog entry...

More Stories By Matthew Pollicove

Matt Pollicove is an Identity Management architect, engineer, trainer, project manager, author and blogger with experience in user account provisioning, data synchronization, virtual directory and password management solutions. As a MaXware Technical Consultant and later as a System Engineer, he worked extensively with MaXware (now SAP) software products in large customer environments. In the past Matt has worked with several leading national and international consulting firms and is currently a Sr. Principal Consultant for Commercium Technologies. He is currently the Practice Lead for SAP NetWeaver Identity Management and SailPoint IIQ.