Thursday, March 21, 2013

The future of SAP GRC

THEFUTURE_id_4414647645_CC_BY_H.L.I.T._29311691@N05There has been quite a bit of  discussion about the potential futures of SAP IDM and SAP GRC. SAP has just started a survey so that they can get customer input. I would encourage all customers using or considering these products to take the poll.

I've worked with the integration between the two products several times now, and I can honestly say that I have never achieved the results that I wanted. As I've thought about the issues that have kept me from getting what I (and of course, my clients) want, it all seems to come down to the architecture.

The way SAP would have it, GRC is the brains, VDS the nervous system, and IDM is the muscle.  IDM workflow does all the work using the various frameworks (Provisioning, Exchange, GRC, Lotus Notes, etc.) while it checks with GRC via VDS to tell it what to do.

The problem as I see it is that there are:
  • Too many moving parts -  IDM, VDS via WebServices to GRC, back to IDM
  • Not enough information that passes back from GRC - We don't see why things are rejected and it's not clear what is happening.
  • A lack of ways that conflicts can be addressed from IDM - This means that the "Security Desk" needs to get involved so they can fix the issue.
So how should this be addressed?  I think through either a tighter integration that is more direct and thicker, that is one where more information is passed, so that IDM becomes the "face" of GRC allowing for mitigation and remediation activities.  However I do not know that the current SAP architecture really supports this. therefore I think it makes more sense for IDM to "consume" GRC and make the GRC functionality part of IDM.

IDM already has a very basic concept of Segregation of Duties through Role Mutual Exclusion functionality.  Having logic that determines what should be "Mutually Excluded" from GRC type functionality makes sense.

However as SAP Roles map to IDM Privileges it would also be necessary for this concept to be extended to the IDM Privilege level.

Finally this new functionality would need to include the ability to implement periodic entitlement reviews (sometimes referred to as attestation or certification) Since in a typical SAP Landscape implementation IDM is connected to HCM with Manager and Organizational properties already defined, IDM is in an excellent position to use it's Presentation Layer, Notifications and Identity Store Database to support this.


Vote_id_4447694983_CC_BY_AlanCleaver_11121568@N06.jpg
This just my opinion and I have registered it via the survey posted above.  Go register yours!


Tuesday, March 19, 2013

Using VDS to Promote Efficiency

Hi there.  I know it's been a while since I posted here, but it's not because I'm not working on NetWeaver IDM or writing.  I've been doing a lot of the former and a bit of the latter.  In order to help promote the growth of a NW IDM technical knowledge base, I've been posting most of my IDM specific things on the SAP Community Network Blog.  I'll still be posting here from time to time, but it will more likely be architectural or opinion related pieces about IDM.

To that point I'd like to talk about the seldom discussed Virtual Directory Server.  I've always loved VDS and it's MaXware predecessor, MVD. There's just so much this product can do. While most of the SAP world is familiar with the Virtual Directory as a Web Services proxy for GRC or use with HCM, it is so powerful and flexible that it can do everything from provisioning to authorization and authentication management, to representing data sources in all kinds of different ways.

That's one of the things I'd like to talk about today.  Ask most Directory Services administrators about a recommended architecture and they will tell you straight out, "flat, as flat as possible."  However there are a number of reasons that this tends not to happen.

So how do we deal with this.  Simple, via the Virtual Directory Server.  Set up the flat structures that the administrators want, then use VDS to  represent the directory with different views, deep organized by geography  department, types of equipment, whatever.  Present the displayname and other attributes as the different divisions request.  Create separate customer facing views of your Identity Data.

Also don't be limited by only using Directory Services information for your Virtual View of data, use the Identity Store, UME and other sources separately or joined together to create your new interface.  Information on this can be found here. The advantage here is that you can create a virtually (if you'll pardon the pun) unlimited number of data representations. Now go forth and create Virtual Directories make your Identity Management group, the "Can do!" group that provides everyone the flexibility that your external customers need while providing the optimal efficiency that the back office wants to deliver.