[00:00] In this lesson, we'll take a look at how to use security levels to control access within a project. To manage our security levels, we can navigate to platform > security > levels. This page lists all of our security levels in a tree format. The placement of these levels is important as a child level will inherit the security of its parent levels. There are four reserved security levels in the platform. The first is the public level. All users are always granted the public security level, even if they haven't logged in yet. Public indicates open access and it's the least secure. The next level is authenticated. Users will need to log in to be granted this access level. Authenticated is a child of the public security level, which means that it inherits that level too. Authenticated is a parent to the next security level, Roles. Roles is a parent placeholder for any potential roles returned from the IdP. We can't configure the roles security level, but more levels can be added underneath roles as children.

[01:04] If an IdP provides role information, these roles are automatically mapped to the child security levels underneath authenticated and roles. The names of these roles must be exact matches with the security levels in order to be mapped correctly. The last reserved security level is security zones. This is another placeholder that acts as a potential parent for all security zones on a gateway, which will be automatically pulled in. We can also create custom security levels to create a new security level. We can click the add level button to edit it. We can make sure it's selected in the tree and then make changes to the details on the right side of the page. If we want to remove a security level, we can make sure it's selected and click the remove level button. If you do make changes, make sure to also click the save changes button to make them permanent. We can add custom security levels anywhere to the tree except under the security zone subtree. The reserved levels have their own specific logic that determines when a user is granted that access level, but we get to add our own logic to custom security levels to determine how the user gets them.

[02:07] I have two custom security levels that have already added to my tree, Upper management and night shift. Upper management is outside of the roles level, but it's still a child of the authenticated level. That means that on top of the custom logic I define that determines if the user gets this level or not. The user must also be authenticated. This can allow me to create a custom group based on information returned from the IdP. The other level I added is night shift. This will also have custom logic that I add to it, but this one is located outside of the authenticated level and under public. That means a user doesn't need to be logged in to acquire this level. It's important to note that because of where it's located in the tree, outside of the authenticated level, I won't have access to user information when adding the custom logic, only public information. To see how to add logic to custom security levels, check out our video on Security Level Rules.