<img src="//pixel.quantserve.com/pixel/p-_JKXxuL8SR7wu.gif?labels=_fp.event.Default" style="display: none;" border="0" height="1" width="1" alt="Quantcast">

Next-Gen CASB Blog

How Bitglass Authentication Works

By Bitglass | May 20, 2015 at 9:40 AM


Welcome. My name is Mike. I'm the director of product management here at Bitglass. Today, I'm going to talk a little bit about how Bitglass inserts itself transparently into traffic destined from an end user to a cloud application.

Today, if you have a cloud app, let's say Salesforce and you want to connect it to Ping Identity, an identity provider, that you have deployed on premise. I have a Ping Instance down here. Then I have users who have laptops and let's say they want to log into Salesforce. They'll come in, they'll make a request to Salesforce through the login page and at that point in time, they'll get redirected. They get a response back that says, "I need you to authenticate and you should do so via Ping." So they're taken to a Ping portal over here, where they enter their usernames and passwords, comes back to the device, the browser refreshes again, and they're taken back at that point in time directly into Salesforce and begin doing their work.

That's great. You have federated identity and you can maintain the identities inside of this. It's an identity fighter. When you come in, and you want to deploy Bitglass, things change but not very much. So I have the same instance over here with Salesforce and I have Ping but now I also have this Bitglass instance. What happens is that when a user comes in to go to Salesforce, the exact same thing happens, they get redirected. The device says, "You need to contact the identity provider." In this case, Bitglass becomes the IDP. Their request comes to Bitglass and we do a look up and we determine that the actual identity is managed by this external Ping instance on premise. So we direct back to Ping, very similar to this other approach over here. User authenticates and they come back to Bitglass.

The difference here is that instead of taking them directly to the cloud app, they come through Bitglass as the final step. Their traffic that is going to be destined for Salesforce, comes to Bitglass first before going to Salesforce. From a session prospective, the user is tied in from their laptop to Bitglass and to Salesforce and Bitglass enforces security controls to perform things like access control, DLP, DRM and what not.

At this point, the session that's established between the client and Bitglass in between Bitglass and Salesforce are two different sessions so if the user comes back up here and they try to open a new browser window and connect directly to Salesorce and login, there is no session there so they get pushed back through the same process again and always ending up being secured by Bitglass no matter what. We provide security regardless of the user's attempts to circumvent it. Thank you. This has been Bitglass Glass Class.