[00:00] Security in Ignition is primarily role-based, meaning your users will have roles assigned to them, and we can check those roles at many different locations. To understand that better, let's take a look at where users and roles can be created. So I'm in the Configure section of my gateway, under Security and Users Roles, and I'm going to take a closer look at my default user sources here. So I click the 'manage users' button on the right and I'm going to head over to the Roles tab at the top here. I'll scroll down here, and you can see that I have three roles configured. Now, it's important to understand that there isn't really any structure to roles. There are no sub-roles or child roles that inherit some other settings from a parent role. Each role stands independently of all the other roles within the user source. Once you have a role created, then you can assign it to one or more users. So I head back to my Users tab here. You can see I've added a couple of users to my system here. The first thing I want to point out is that my Admin user here now has all three roles. So it is possible to give each user multiple roles. Additionally, I have a guest user here without any roles at all. So you could create a guest account or have a restricted user by withholding roles from that user. The way security normally works in Ignition, is that you can restrict some resource. So for example, maybe an entire window in one of my clients here. I can say that only operator should have access to that. So I can place a restriction, checking for the operator role. In that scenario, my admin user and my operator user would have access to it, while maintenance, or maint and guest, would not have access. This is one of two models you can use to restrict access to resources. By model, I mean "How do you want to handle your higher level users" here? In this scenario, I have given my admin user all of the roles possible. So that way my admin user always has access to everything in the entire system. This is certainly the easier model. The alternative model, though, if I switch over to this tab here - another user source I have - involves giving the least amount of roles to any user. In that same scenario, if I wanted to limit access to a window except for my administrators, and my operators, what I'd need to do is check for both roles on that resource. So I could have my window, when it opens, check for either the administrator role or the operator role. If the user has either one of those, they have access. Both models work great. Decide which one you want to use early on, and stick with it. It'll make your life a lot easier as you're adding more users and roles to the system.