Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

151106_Via_Whiteboard_JMandelbaum

0 (0 Likes / 0 Dislikes)
Hello. My name is James Mandelbaum. I'm the Pre-Sales Identity Architect for the Americas. What I'm going to do today is give you an overview of how I've learned to whiteboard Via Access and how articulate the differences between what we offer and what the other players like the Ping and the Oktas of the world offer. And before I start my presentation, I always like to kind of see the question, "Is single sign-on about security or is it about convenience?"

Now there's always the one hold out in the group that always says it's about security. And I challenge them and ask them. "Can you explain to me how it's about security?" And I usually like to ask them the question, "If I manage to steal your identity. Am I sitting on a plane next to you and I manage to see your username and your password, walk off to a kiosk once I get to the airport. Log in. How do you know that I've done that?" What safeguards are in place to prevent me from getting in with your identity and then moving laterally around your network through your applications or even through your VPN?

So I like to see that before I begin into my Whiteboard. As we begin the Whiteboard, we break it down to the three distinct areas. First is On Net, your On Prem. And we'll typically have AD or LDAP, may or may not have secure IDM place or legacy installed. And most certainly, we'll have some Web Apps, those are the SharePoints, the other web-based portals that they have on prem. In the DMZ, we may or may not have Web Apps. But in the Cloud we know most certainly will have the O365, the Salesforces, the Workdays, the other SAS apps that live out in the Cloud, as well as the Third Party Legacy Apps.

You know, in training, we used RAI as an example or the Museum of Modern Art. These are really Web Apps that you have no control over, but these are the things that have a form. So you input a username, then put a password, click the submit button. These are what referred to as the Third Party Legacy apps. When we look at traditional providers, the things in the Octus, what they will typically do is put an On Prem connector. They can call it an Agent. They can call it a Federation Server. They can call whatever they want, but it's something that installs on your network. It basically proxies to a Cloud instance that's maintained by them. And the questions you need to ask the client is, "Where are they going? Where does this Cloud instance exist?

How is it protected? What safeguards are in place? Who can view it? How is it protected in the issuance of, say there is a breach? How are they notified? How are they protected?" Start instilling the idea that they have no control over their identities. Not a lot of the... lot of instances, there are governance rules and policies that specifically state that this cannot exist in their environments. Therefore, a hybrid approach is more appropriate. And this is what we do. The first thing we do is we give you a VM. It's an OVA file that you deploy On Prem in your DMZ recommended. It has two network cards on it. One is for management, one is for portal access. And the idea is we segregate the traffic and protect the traffic. What that means is your identities stay on your network.

They live on your network. They don't leave your network. And you have total control of it. So the first thing we do is we create a connection between your AD or LDAP. If you have securID, we create that connection. But most importantly, the identities stay on the Prem. So first and foremost, what is that Identity Router? Well, right off the bat, it's a portal. I have a laptop. I log in to the portal, based upon contextual awareness, meaning I'm looking at how I'm coming in from the network. I'm looking at my AD or my LDAP groups. I'm going to get a group of icons and I have access to those applications. That simplifies my administration, which means I don't have to push out URLs to clients. I don't have to notify them that a new application's been added when they log into the portal. It's automatic for them. It really does make life easier and it simplifies things from a security point of view as well.

The next thing that the Identity Router is, is it provides that SAML connection. So when we look at connecting to the SaaS Apps, we support SAML in both in IdP and in SP mode, meaning an Identity Provider and a Service Provider mode. And we support Deep Linking. What that means very simply, is if you're trying to go to a specific location within their SaaS App, you don't have to log in to the first place, and then go through. If that SaaS App supports it, most do. You can simplify the user experience and provide them direct access to a specific location within the SaaS App. The other thing we leverage is something called Password Federation. You've heard of WS-Fed. We call it H-Fed. And what that does is that gives us access to these form based legacy apps. And I very simply say, if it asked you for a username and a password, and you can click the Submit button, we can support you. Now how that is accomplished is through a reversed proxy. This laptop connects to the Identity Router. The Identity Router, on our behalf, connects to the Web Apps. What's really cool about that is as soon as that happens, we can turn on logging, which means we can get true context of what the users are doing while they are connecting to it. The other thing we get with that is we get access not only to the Off Prem stuff, but we get access to our DMZ and our On Net Apps. What that does is gives us, again, a single portal for all of our apps whether they are On Prem and Off Prem. Again, I brought up the idea of audit logs. But now let's talk about the true contextual awareness piece of this. What about Off Net? So if I'm logging in, let's say I'm going in directly into the Identity Router with my username and password, I may not get all the same icons that I would if I was On Net. We also look at whether I'm coming in through a VAM or I'm coming in through a VPN, these are all the different IP subnets. We can look at that and provide contextual awareness. Now there is a couple of things you get with that. Number one, we get to determine what apps we get. We also get to determine some security models that are based around that. I'm going to come back to that in a minute. But there's something else that you get with this that's really cool. What we can do is we can take Off Net users, connect them through the Identity Router, only provide them access to the apps that you want, which in this case are Web Apps. But what that does is they don't need to be on the VPN anymore. A lot of use cases for VPN are strictly for Web Apps. What I can do by giving them Web App access through the Identity Router is I can remove them from the VPN, thus reducing risk. This is all about reducing risk, making it easier for our users, but providing security. It solves a lot of things that right now are being solved through multiple solutions. We can put it into a single solution and solve many issues while reducing the risk footprint across the board. So I brought up the contextual awareness, I've talked about the fact that we can look at how you are coming in. We also need to take in context the application value themselves. So if I'm coming into an application that's considered risky, whether it's the means of how I'm coming onboard, the value of the asset, meaning the application, as well as my AD context. Then we start looking at, well, I need to come up with ways of challenging. So what we've done is we have a mobile app that allows you to put a step up process into the method. So if I'm... whether I'm on the network and I've come in using Integrated Windows Authentication, right in. So I didn't actually have to log in to the portal. I'm coming in Off Network, or I'm coming in through a VPN. It's gonna look at this and say, based upon this policy, based upon this scheme, I'm going to challenge you. And how am I gonna challenge you depends upon those policies and rules. Now we can start it simple as a registered mobile device, that's a push technology. I come in, I click on the app, minimally obtrusive, my phone beeps, the app pops up and says "Do you want to allow access to Office 365?" Yes, I do. And the user is let right through. The key thing here is pivoting security backend, while minimally creating the roadblocks to the user. It's all about the user experience. Again, we all know that if we make the user experience difficult, the users complain and the project usually gets pushed back and potentially fails. So we built in a whole bunch of solutions into how we do the step up. First and foremost, is Push technology. We have an AppToken. So if you fire up the app, slide your finger across, there's an actual token that comes up. Where that's great is, it is an additional step up feature, it requires positive action by the user. But it also is a great method, if for example, if I'm trying to log in and I don't have mobile cellular signal or I'm traveling and I can't... international and I don't have signal there, I can use a token and still get in. We're not disrupting the process. That's how we make sure that we always have access. We also can take the next level of authentication and that's biometrics. So we build in to the touch, into the iOS devices. And very shortly, we'll have fingerprint technology in several of the Android devices out there. And ultimately, as I mentioned before, we have integration with securID, so we can use that securID token. Now that's great for the ultimate of security. I have a high risk application. I have a high risk use case, where they're coming in Off Net. And you can determine how you want to do that. But it's also great, it's come up recently with we have users that have Windows mobiles and Blackberry devices that we don't have support for the Via App, because right now it's in iOS and Android. We can make sure that we still satisfy those needs. Now, one thing that always comes up is, "How do I register the device?" It's very simple. It's done directly in the app. You provide them your identity information to them. They log in and register the app. It's actually very simple to do. Now I did bring up earlier that this is a hybrid approach. So we want to make sure that we explain to the users what does that mean. So the identities are retained On Prem through that Identity Router. We want to make sure that that is clear, but there are things they need to do in the Cloud. Creating the policies and the rules, how the step up occurs, and what the step up methods are. They can create multiple schemes depending upon all the different criteria to build that policy, 'cause you can see, based upon how they are coming in, the value of the assets, AD groups that can get very complex and as robust as they want to make the policies, so they can build them. So you have that piece. The other piece you have is building of the applications. So what we do is we build the application in the management portal. We have a catalogue of applications for SAML apps as well as Federation Apps. And we have wizards that walk them through on-boarding applications. Common question is how long does it take to onboard an application. The easiest way I can explain that is when we went through training, we were all asked to onboard a third party website. I chose RAI. So the very first time I did it, it took me about 15 minutes, start to finish, to onboard an application that was not SAML. It was Federation, which is more difficult. So you can get the idea that it is actually very easy through our wizard system to onboard applications. But again, we're adding applications for application catalogue on a regular basis and that is growing every day. So it may be as simple as add an application, choose the application from the list, provide the simple SAML information they need specific to their instance and away they go. So they'll add the application in the portal. They'll create the rules around that application. They click Apply. And it pushes that information down to the Identity Router. The other thing we're doing with the idea of that management portal and the multitenant architecture up in the management portal is the ability to provide rapid updates. So as new features come out in the system, we can push it right into the management portal. And when they click Apply, that information can then be pushed down into their Identity Routers. So there's not a lot of maintenance on their behalf that they have to deal with. We're taking that care of that for them. The other piece, the third piece to this is the Push Engine. They're not expected to have to go maintain the relationship between Google and Apple. We take care of that for them. So if you have any questions, you have my contact information. Feel free to reach out. I'll be glad to answer any questions. And this deck will be made available to you, so you can tweak it to meet your needs. Thank you very much, and good selling.

Video Details

Duration: 13 minutes and 16 seconds
Country:
Language: English
License: All rights reserved
Genre: None
Views: 4
Posted by: quinnb on Mar 28, 2016

151106_Via_Whiteboard_JMandelbaum

Caption and Translate

    Sign In/Register for Dotsub above to caption this video.