casb is eating the idaas market

This post was originally published here by Rich Campagna.

In the past 6-9 months, I’ve noticed a trend amongst Bitglass customers where more and more of them are opting to use the identity capabilities built into our CASB in lieu of a dedicated Identity as a Service (IDaaS) product. As CASB identity functionality has evolved, there is less need for a separate, standalone product in this space and we are seeing the beginnings of CASBs eating the IDaaS market.

A few years back, Bitglass’ initial identity capabilities consisted solely of our SAML proxy, which ensures that even if a user goes direct to a cloud application from an unmanaged device and on a public network, they are transparently redirected into Bitglass’ proxies – without agents!

From there, customer demand lead us to build Active Directory synchronization capability for group and user management, authentication directly against AD, and native multifactor authentication. Next came SCIM support and the ability to provide SSO not only for sanctioned/protected cloud applications, but any application. 

So what’s left? If you look at Gartner’s Magic Quadrant for Identity and Access Management as a Service, Worldwide*, Greg Kreizmann and Neil Wynne break IDaaS capabilities into three categories:

  • Identity Governance and Administration – “At a minimum, the vendor’s service is able to automate synchronization (adds, changes and deletions) of identities held by the service or obtained from customers’ identity repositories to target applications and other repositories. The vendor also must provide a way for customers’ administrators to manage identities directly through an IDaaS administrative interface, and allow users to reset their passwords. In addition, vendors may offer deeper functionality, such as supporting identity life cycle processes, automated provisioning of accounts among heterogeneous systems, access requests (including self-service), and governance over user access to critical systems via workflows for policy enforcement, as well as for access certification processes. Additional capabilities may include role management and access certification.
  • Access – “Access includes user authentication, single sign-on (SSO) and authorization enforcement. At a minimum, the vendor provides authentication and SSO to target applications using web proxies and federation standards. Vendors also may offer ways to vault and replay passwords to get to SSO when federation standards are not supported by the applications. Most vendors offer additional authentication methods — their own or through integration with third-party authentication products.
  • Identity log monitoring and reporting – “The vendor logs IGA and access events, makes the log data available to customers for their own analysis, and provides customers with a reporting capability to answer the questions, ‘Who has been granted access to which target systems and when?’ and ‘Who has accessed those target systems and when?’”

Check, check, and check! Not only do leading CASBs offer these capabilities as part of their cloud data protection suites, in some cases, they go quite a bit farther. Take logging and reporting for example. An IDaaS product sees login and logout events, but nothing that happens during the session. CASBs can log and report on every single transaction – login, logout and everything in between. 

Another example is multifactor authentication. Whereas an IDaaS can trigger MFA at the beginning of a session due to a suspicious context, a CASB can trigger MFA at any time – such as mid-session if a user starts to exhibit risk behaviors. 

Since these capabilities have evolved as part of CASBs, which offer comprehensive data protection capabilities for cloud applications, I expect that 2017 will be a year with a lot more enterprises considering CASB platforms for both cloud identity and cloud data protection. 



No posts to display