In this video we're going to do a high level architectural walk through of Cloud Access Manager 8.1. This isn't meant necessarily to be a deep dive into the technology. Obviously that's something that would take a lot more time to cover. But this is certainly enough to give you the information you need to know. What's deployed in your environment, and how those pieces are working with each other.
So the first thing we want to do is actually take a look at a simple drawing. So the diagram you're seeing here is a typical deployment. Your mileage may vary, that's fine. But typically this is how we deploy Cloud Access Manager. If you think about the user being on the left hand side over here, that user out on the internet is going to be connecting to a proxy, which is installed in the DMZ. It's a very lightweight service that's running here.
This server is making calls to the Cloud Access Manager core server behind your firewall. This is what we call the secure token server or the core server. And of course, this server's what's making your authentication calls to Active Directory, LDAP, et cetera. And then finally, there's a data store for Cloud Access Manager that's in your SQL environment.
Later in this video, we'll talk about high availability and failover and what that looks like. But before we do, I actually like to draw this out in Visio and walk people through the architecture in real time, basically how the pieces are communicating with each other. So let's go take a look at that
OK. So let's start from scratch. Again, showing a typical deployment of Cloud Access Manager. We put a firewall out, and we think about the Cloud Access Manager proxy basically sitting on the firewall. Let's give that a name. Behind your firewall is our secure token server, what I call the core server. And then of course, we realize that there's a SQL database out here that Cloud Access Manager is connected to. This is where my policies are stored, application definitions are stored, user security groups, et cetera.
And then of course there's the notion of a directory that we're going to be authenticating users against. For this design we'll just go ahead and say this is Active Directory, and that's sitting over here. OK. We'll put this here, put this here, and let's bring this to front.
Meanwhile, the first walk through we're going to do is a user that's at home or out on the internet. We'll say this is me. And what I want to do is get access to my Salesforce account. So of course there are a number of ways I can do this.
Let's take a look at an SP initiated federation scenario. That's were Joe connects first to Salesforce and Salesforce says, I don't know who you are. So I'm going to redirect you to your company's IDP. Basically Joe's browser gets a redirect command to go over to Cloud Access Manager and authenticate. That's where Cloud Access Manager is going to say, if you have a session with me already, then I'm going to perform single sign on. If you don't, then I basically need to authenticate you.
So the proxy is actually going to go behind the firewall. And say, I don't know who this person is. There's no active session for him. So show me a login screen. The login screen actually is rendered from here, but it's sent through the proxy to Joe.
Now here's where he can put in his user ID and his password. We could elevate him to multi-factor authentication if we need to. But at some point we're just going to get this credentials. We're going to send those through to the core server, and it's going to challenge those credentials against Active Directory.
Now, once we've done that, we've authenticated the user. We go look in our policy database and we say, all right, we know who the user is. We know the target he's trying to get to. What do we need to do? And it's going to say he's allowed to get there. Go ahead and generate a token for him.
So in this case we're going to generate a simple SAML token, and send that back through the proxy to Joe. And we're going to send an instruction to his browser to go back to Salesforce and login. So he's going to log in over here. He's going to post his SAML token into Salesforce. Salesforce is going to read that token. It's going to know it came from a trusted source. And Joe's essentially going to get logged in. So now he's got a cookie here. There's going to be a cookie over here on the proxy server. And now comes a different type of scenario. Let's change it up a little bit.
Joe gets a text message. Someone tells him, hey you've got a login and update a record in the HR system. Now it just so happens though that the HR system is behind the company's firewall. And that system is secured with a login form. So basically any user that attaches to that system it's going to get shown a user ID in the text box. Or maybe it's Windows authentication, basic authentication. It could be Federated. Really it doesn't matter. But for this scenario we're going to say that it's using a login form.
So all Joe has to do is type in the URL for that website. That's essentially going to get him intercepted by the Cloud Access Manager proxy. And now this time we've already authenticated the user, right. We're going to have a single sign on happening here. Cloud Access Manager is going to say, look I already know who this user is. We've already authenticated him. But he's trying to get access to the HR system. Is that allowed? We're going
16:29