[00:00] Security levels are new to Ignition 8 and are used to determine what level of access a user has within the system. Security Levels are set up for the entire Gateway and Identity Providers can provide information that places users into certain levels. To manage our Security Levels, we first to come into the Gateway Webpage and go to the Configure section. Once here, we then need to find the Security Levels page on the left underneath the Security heading. On this page, we see all of our Security Levels listed out in a tree format. If we wanted to add a new Security Level, we simply need to click on the Add Security Level button in the lower right. If we wanted to edit or remove a Security Level, we first need to click on the Security Level and then on the right-hand side we can make changes to it or click on the Delete button to remove the level altogether. Once we've made all of our changes to the Security Levels, we then need to scroll down and click on the Save button to save our changes to the Security Levels. When managing your Security Levels, it is important to keep track of where the level is located, as this will determine when a user is assigned that level or not. There are few prebuilt Security Levels that help us place our Security Levels into categories. For example, at the very top of our list of Security Levels, we have the Public level. The Public level is actually available to everyone, even if you haven't authenticated against an Identity Provider yet. This means that if a component in a project was designated as having a public access level, anybody that accesses that project, even if they haven't logged in, can use that component. From here, drilling down further generally means a more secure level. One of the next levels down is the Authenticated level. A user is assigned the Authenticated level if they have authenticated against an Identity Provider. At this point, the Authenticated Security Level doesn't care who the user is, what roles they might have, or which Identity Provider they authenticated against. All that matters is that the user did authenticate against an Identity Provider. If they did, they are granted this Security Level. So, designated a component as requiring the Authenticated Security Level means that the user needs to log in before they can use that component. Now as I mentioned earlier, where the Security Level is placed within this list is very important and that's because it determines what type of Security Level we're going to be dealing with. There are three main types of Security Levels. Security levels that correspond to roles, Security Levels that correspond to Security Zones, and then custom Security Levels. For the most part, like the Public and Authenticated levels, each Security Level has some logic behind it that determines when that user is granted that level. The logic running behind each level is determined by the type of Security Level. For example, the first type of Security Level is the Security Level tied to a role. If we drill down into the Authenticated section, we find the Roles section. The Roles section itself doesn't have any logic behind it, but it contains a list of Security Levels that are driven by the roles that the user has. The roles that the user has is determined by the Identity Provider. So if a user authenticates against an Identity Provider and the Identity Provider returns to us that the user has a role called Maintenance and a role called Manager, then it's going to assign them those appropriate levels. Because all Identity Providers use these same Security Levels and because we don't know the roles that are within the Identity Provider before we authenticate, you do have to manually enter in all of the roles for each of your Identity Providers here. You do need to ensure a name of the Security Level that you create in this Roles section matches up to the name of the role that the user might have within the Identity Provider. Because each of the Security Levels within the Roles section corresponds to a user role, you'll notice that we can't nest these levels within one another. If I select one of my Security Levels corresponding to a role, I can't add a new one underneath it. The second type of Security Level are the Security Levels that correspond to Security Zones. Like the Security Levels tied to roles, the security tied to Security Zones has logic that's determined for us. If the user falls into a particular Security Zone, they get the get the corresponding Security Level for that zone. However, unlike the levels tied to roles, the Security Levels for Security Zones are actually created for us. Meaning, when I create a new Security Zone, a corresponding Security Level is automatically created for me. Additionally, you'll notice that I can't even add a new Security Level into the Security Zone section. Finally, the last type of Security Level is the Custom Security Level. The Custom Security Levels are unique in that we can actually build the logic behind them that determines when a user is assigned to that level. In my list here, I actually have two Custom Security Levels, Upper Management and Night Shift. Both of them work a little bit differently from one another. You'll notice the Upper Management level lies outside of the Roles section, but inside of the Authenticated section. This means that in addition to whatever logic I put behind it that will determine whether a user falls into that level or not, the user also needs to be authenticated. Typically, these Security Levels are used to group users more effectively than the roles that we get from the Identity Provider. Like the Upper Management level, the Night Shift Security Level allows me to place custom logic behind it that determines when a user is granted that level. However, unlike the Upper Management Security Level, Night Shift falls under the Public Security Level. Because it is outside of the Authenticated level, a user does not need to have authenticated against an Identity Provider to be granted this level. This means that any user, even if they haven't authenticated, can be granted this level, as long as they meet the requirements set forth by the logic behind the level. One thing to keep in mind for the Custom levels outside of the Authenticated level is that because users may not have authenticated yet, we can't check user-based information within these levels' logic. We can only use information available publicly. Now when you set up these Custom Security Levels, the next thing that you need to do is set up the logic that determines when a user falls into those levels. We will take a look at how to set up that logic in the next video, Security Level Rules.