They say sometimes a picture is worth 1,000 words and the idea of giving you a picture is to give you a visual representation of what the DMZ looks like after we've discussed it. When we think about trust relationships, now that that we've laid out the different Internet network architectures, and we think about trust relationships we're thinking about the different kinds of trust relationships or trust in general that we have inside of the system. And if we go back for just a minute to our DMZ design we can illustrate trust very easily using the diagram here. So if we think about a machine in the DMZ, any one of these threes that's just sitting right here, and we think about the fact that they may need to access resources on one of the machines, behind the secondary firewall on the internal network. And they have to do so by way of authentication, they have to provide some sort of credential to prove who they are, so that the internal machine will trust that access request and allow it to take place. We are thinking about trust in relation to something that is tangible, that with regards to access control, with regards to consumption of services through this particular architecture, that we can actually point to, that's tangible, that we can measure, we can manage and we can control. Trust in other words can be implied, but trust can also be measured. And when we think about the trust or the nature of a trust relationship, we have to think about what's known as the trust path. And the trust path is we define it for you on the screen, is a series of trust relationships that authentication requests like the one we were just envisioning may happen from the DMZ backwards in to the Internet, will follow between domains. The idea behind a trust path is representing the steps or the path that, I as a user may have to go through as I request or authenticate to access services, and be granted those accesses or that access to those services in a domain that either I'm a member of or through what are called trust relationships I can gain access to. And so if we go back to our diagram, again just using it as an example, and if we think about the fact that somebody that is outside of the diagram in theory sitting over here in the cloud, out in the intranet, outside of the firewall or excuse me, outside the external firewall inside the DMZ in the Internet. If we think about somebody sitting out here as a user, if they are a member of the domain that is inside on the internal network, they would have to traverse, they would have to come through the external firewall, through the DMZ, through the internal firewall, and then gain access to one or more of the systems here by representing their credentials and having them passed through the trust path, whatever that path may look like. If, however, they are outside but they are not a member of the domain, we may not be able to give them a clear path that gets them access to the internal network, because they won't be able to represent their credentials in a way that validates the trust path, and allows them access. And so the trust path is only available to authenticated users, users that can actually traverse it because they have credentials that will open the door. That allows them to move through various stages of the trust path. We can think of a trust path in another way, and so, if we go in here for just a minute and we take a look at the Internet Explorer. So if we open up Internet Explorer generically, and we go in and we look at Internet Options here. And what we will find is if we go in to Content and we go to Certificates. And inside of our certificates here we go and we look at, let's say, anyone of the intermediate certificate authority certificates. You can see them on the screen in front of you, and I'll go to the one here that is from GoDaddy. If I take a look at this, and I open it up and I look at the certification path, I could see another example of what a trust path may look like. This trust path over here is going to go from the GoDaddy root certificate authority down to the certificate authority that I'm looking at, the certificate that was issued by it, which is the intermediate authority. And there's a path there and I can go up the path, and I can see information about each area of the path, as I move up you can see I can view the certificate from the root certification authority. And by doing that I can see where it comes from, what it's used for, I can see the certification path ends there, and I can see the details of it. This is not quite the same thing as the trust path we're talking about, but it's a very similar concept. And it's a visual that helps you to understand the concept of the trust path. Walking through the various stages of where the certificate comes from, until we find the last certificate issued in the chain, and moving back up the chain to validate that each level of the trust chain is indeed valid and appropriate, it's the same idea that the trust path represents to us. And so we can see this concept of trust or this concept of paths existing in multiple places, and as we think about the trust path, we're thinking about this relationship that allows us to understand that, domain A may or may not trust domain B. And a user from domain B would only be able to access resources in domain A, if domain A and B agree that they're going to trust each other, and provide a conduit, a pathway. That would allow users from domain B to be authenticated and therefore granted access to resources in domain A. That would represent the trust path, and that's one of the things we have to think about as we're authenticating and as we're dealing with access control related concerns. A one way trust in this case would be a trust that is what we call unidirectional, that trust relationship would go from one domain to another but only one way. If we use the example of domain A and B again, if domain A has a unidirectional or one way trust with domain B, domain A's users trust domain B. Which means that domain A users may be able to allow, or domain A resources, may be able to allow domain B users to come in and use resources. But because it's not a two-way trust, it's not reciprocal, only one domain trusting one way. The other domain cannot access the resources, only one domain can. And so a single one-way trust implies that domain A would trust domain B, meaning domain B's resources and users can interact with what's in domain A, but domain B does not trust domain A. And so therefore domain B's access, resources, users, etc. It's not available to domain A, it's just a one way trust, allowing the domain B users and the domain B resources effectively to interact with domain A but not reciprocate it. So when we want to reciprocate that, we create what's called a two way trust. And a two way trust allows both domains to effectively create a relationship with each other. You imagine that we have two systems A and B, we create an arrow from one to the other, that is a one way trust. Another arrow going the other way, to complete a circuit if you will, and we have two domains each trusting the other. Both users and resources in either set of domains will be able to interact with, use, and trust the set of resources and users from the other domain, because we have what is known as a two way trust.
