Hello and welcome back. In this lesson, we are going to talk about enforcing access control with session management. Specifically, we're going to talk about what access control is and the relationship between authentication, session management and access control. Then, we're going to talk about the two different kinds of privilege attacks including, vertical and horizontal. Last, we're going to talk about specifying explicitly about how users are going to be able to access resources and how they will be able to do that. At the end of this lesson, you'll be able to distinguish the relationship between authentication, session management and access control. Let's get started. Access control can be defined using three components. First, there's the principle. A principle is a user or a processor machine. The second component is the action that is allowed by that principle. The third component is the resource to be acted upon by that principle. Basically, we want to define how we can control which principle is allowed to access which resources. Access control only makes sense if you know what you're protecting. There are several kinds of access control models. One we're going to talk about, specifically is called role-based access control and that's where users are assigned to functional roles like for example: administrator or regular user or guest. These different functional roles have different sets of privileges. Now, there are other kinds. One that I can mention here is discretionary access control and that's where owners of resources grant access to other users to access their resources. If those owners of those resources don't explicitly grant access to those resources, access is automatically denied. Another access control model is something called identity-based access control. That's where a user is allowed access to a resource only if they appear in a certain whitelist of allowed users for that particular resource. There are several more that aren't mentioned here, but you can find the others online. Again, to simplify we're going to focus on role-based access control in this video. Looking at the bigger picture, authentication validates the principles identity and initiates this creation of the session. Recall that session management keeps track of the state while the application is in use. During this session, access control acts as a gatekeeper to application resources. Notice in this diagram that access control is in its own component. It's best practice to make sure that the functionality for access control is in its own centralized module, so that programming mistakes are reduced as well as for making functional testing easier. Moving on to the two broad privilege attack types. The first kind is called vertical privilege attack. These are attacks where an attacker attempts to gain more abilities to be able to modify or act upon a resource. For example, when an attacker starts out as a user with regular user privileges, then escalates their privileges to be able to gain administrator user privileges. In contrast, horizontal privilege attacks are when an attacker is able to access more than the resources to which he or she has been given access. For example, if initially I am user one and it was intended that I could only access or act upon file one, but it turns out that because of a flaw in the web application I can also act upon file two, which I as user one I'm not supposed to access because I don't own it and user two owns it. So, that is an example of a horizontal privilege attack. What we want to do to make sure that we create a good access control system for our web application is during the design phase, we want to specify specifically who or what has access to which resource and how. You can specify your access control policy using a tuple of principle, access type and resource. For example, here I have the principle of employee. My access type is "put". So, I'm talking in terms of a restful action here. My resource is emp1/resource.jpg. However, when you have many principles, expressing your access control policy in this manner can be cumbersome because if you could imagine, if you have many principles, you would have a huge list of tuples. What is commonly done is to squash the first column of principles into, basically bucket them into groups or roles. A group is the function assumed by a user at a particular time. For example, at an administrator or a regular user or a guest for example. So now, here are some best practices for setting up an access control system in your web application. What I had mentioned previously is we want to explicitly design your access control security policy. Another thing you want to make sure to do is to express the access rights during a session on the server side. So in other words, don't trust any user controlled data to signify access rights. So you could imagine a counter example is, if a URL has admin equals true on it and that is how the web application signifies whether the access for admin rights is true or is okay. Now, in this case we wouldn't want to do that because that is incomplete control by the client side. We don't want to trust that data. Another thing that we want to do is to always validate user controlled data. We want to make sure to have the access control functionality placed in a centralized component. So for example, in a module that is specifically designed for access control functions, you also want to make sure that every request is checked against the centralized access control function before allowing any access to a resource. Additionally, you could restrict special pages like admin pages using an IP access whitelist. For any critical actions like for example, some critical admin action, you want to re-authenticate that user before performing that critical action. In summary, we talked about what access control is and how it's related to session management and authentication. We talked about the two kinds of privilege attacks and we also mentioned this idea of specifying explicitly our access control security policy. That's it for now. Thank you.