[00:00] When setting up Security Levels, you may set up some custom Security Levels that need special logic behind them that determine when a user falls into that level. That logic is called Security Level Rules. In my list of Security Levels here I have two custom Security Levels: Upper management and night shift, and both of them have Security Level Rules that determine when users fall into those levels. To configure the Security Level Rules, you first need to go to the Identity Providers page. So on the left hand side, I'm going to click on the Identity Providers page under the security heading. Here we see a list of all of our Identity Providers. Each Identity Provider can have its own set of Security Level Rules. I need to find the provider that I want to set up rules for, and click on the more button and then go to Security Level Rules. Here we see a list of all the Security Levels that can have a logic added to them as well as their parent levels. You'll notice the public and authenticated levels are listed here, but I can't actually add any logic behind them, because their logic is already determined. To add Security Level Rules to a Security Level, you simply need to click on the Security Level that you want to add some rules to. And then on the right hand side, provide the rules in the form of an expression. Once you've made your changes, you can hit the save changes button down at the bottom right to save the Security Level Rules. Now as I mentioned, the Security Level Rules are built using the expression language. Which means you have all of the expression functions available to you. You can also pull in any Tag values that you might need, to set up your rule. My night shift Security Level is using the timeBetween expression function to check whether the current time is between the hours of 6:00 p.m. and 6:00 a.m. If the current time is between those two times, then the user will be granted the night shift level. Note that because the night shift level is outside of the authenticated level, the user doesn't need to be logged in to be granted this level. I can use this to provide some special functionality to any of my users who work during the night shift. The upper management Security Level is using two special pieces in its expression. First, because the upper management level is underneath the authenticated level, that means that we can pull information from the Identity Provider related to the user. You'll notice I've done that here, using the special reference idp-attributes: the name of the attribute that I want to reference, in this case roles. This will provide me with a list of all of the roles that the user has. The second special thing is the expression function containsAny. containsAny and its counterpart containsAll, check to see whether any or all of a number of values are contained within a list of values. So in this example here, I am first grabbing the list of roles that the user has assigned to them by the Identity Provider. I am then checking to see if the manager role, supervisor role, administrator role or director role is present within their list of roles. If any of those roles are present for the user, then that user is granted the upper management Security Level. This can make it easy to assign functionality to a large group of users. Instead of assigning all role levels that might be able to use a certain component, I can simply allow the upper management level to use that component and provide that level for users that fall in that category.