Yesterday CA announced its acquisition of IDFocus, a small Israeli company. Among other abilities, IDFocus provides a finer-grained segregation of duty (SoD) analysis engine. CA has previously integrated this engine into Identity Manager, their user provisioning tool.
This is an interesting wrinkle in an ever-changing market. CA now possesses a preventive-controls engine with the ability to look further into the security stack of an application. This engine allows customers to make SoD decisions below the role or group level, at the lower ACL/security object levels. Provisioning vendors have until now done this by calling external services provided by Enterprise Application Controls Management (EACM) vendors.
On one hand, CA has partially obviated the need to integrate with an SAP, Oracle, or Approva by integrating the IDFocus capabilities into CA Identity Manager. On the other hand, CA’s move may have made things more confusing for customers. By increasing the number of controls repositories that a customer has to maintain, integration of IDFocus makes compliant provisioning deployments more challenging. What would be really slick is if CA could find a way to work with the EACM vendors to synchronize SOD tests so that a customer could use the same test for both detective and preventive applications.
I was speaking on this very topic in Europe last week. I commented on the various architectures for integrating EACM into user provisioning to provide compliant provisioning services. (For more on this subject, check out Lori’s report on the matter.) CA has now introduced a fourth deployment model in which the provisioning engine owns the entire compliant provisioning event from the request through the SoD test to the provisioning event itself. An interesting alternative. I’ll be curious to see where CA takes this.
(Originally post on Burton Groups’ IdPS blog.)
On one hand I can’t say I am that surprised. SAP has been itching to get into the IdM market. There was speculation that they were going to build their own. It is interesting to see that they have chosen, as many others have, to buy instead. I am, however, a little surprised in who SAP purchased.
MaXware was known, primarily, as one of the three major meta/virtual directory companies out there. Maybe SAP saw wisdom in Oracle buying OctetString? (I’d be feeling pretty lonely right now if I was Radiant Logic.) Maybe SAP really just needed the connectivity that MaXware could provide?
I wonder what this means for corporate SAP partners who are already in the identity management space? If I am a provisioning vendor who has spent resources developing integration to SAP and the Virsa bits, I am going to be pretty annoyed that SAP just bought a provisioning technology. Integration partner one day, direct competitor another.
The real reason SAP made this move is the continuing SAP – Oracle War. SAP needs to be able to check the boxes off in an RFP that they have provisioning and identity management services. If SAP is looking to even the playing field, there’s at least one more acquisitions they have to do. They need to buy a large services company likes of Accenture or Booz Allen Hamilton. Granted, doing that will agitate their service partners, but that being said, it would round off SAP and enable them to go toe-to-toe with Oracle.
In closing, I wanted to include a few insightful thoughts from Jackson Shaw. I just discovered his blog… good stuff. Jackson writes:
SAP AG is acquiring MaxWare because they believe that if they can control identities, security and roles from within SAP NetWeaver then they can “own” an organization. They can be the tail that wags the dog.The few systems that SAP GRC can connect today stands out like a sore thumb. Who could take them seriously? Now, with MaxWare they’ll be able to connect to many more systems but will they be taken seriously?
If IBM can’t do it with WebSphere and Tivoli, I don’t see how SAP can do it with NetWeaver.