 But I will get started then. Let me get my clicker at the ready. Authorized, it's not a yes-no question. We are probably mostly all familiar with the idea of knowing whether or not somebody is logged in. We can do things in our applications that will either work if they're logged in or not if they're logged out. We have this idea of authenticated. We also have ways of building these login mechanisms really easily. This is a screenshot from Laravel. But you've also got Django's auth capabilities. And even Flask has a login mechanism that will handle some of the underlying features of authentication and manage a username password type login mechanism. But the thing that all of these have an issue with, I've skipped one slide ahead already. The other option is just not even writing your own login form and going with something like a social login. So just log in with Twitter or Google or one of the other social media type logins. And at least that way, you know whether or not they're logged in and you get a little bit of user information about them as well from the social login provider that you're using. But like I was about to say, the problem with these is that you only get a yes-no answer. Are they logged in or are they not? We don't get any more nuanced information about who they are. We can't do things like, do they have permission to do something? We have no concept yet of whether or not they have these permissions. So my name is Ben Decray. I've been a software developer now for 21 years. That number keeps going up. And the little emoji that I've got there of the old man is certainly how I feel sometimes when I think about how long I've been a software developer for. But I do love it. It's something I have great passion for. I love the developer community as well. And I've been involved in the conference talks for almost all of those 21 years, probably about 15, 16 years. I am a huge, I'm hugely passionate for the developer and open source communities. And I'm also very passionate about privacy, advocacy, and civil liberties and all the things that kind of run in that sphere. So two years ago, almost to the day, what are we, the second of October now, 17th of last month was my two-year anniversary at All Zero. And I joined mainly because they love supporting the community and the developers, their inter-security. And it was another way for me to be able to go out and meet people at conferences and events back in. Do you remember when we still were allowed to fly? I barely remember it, but I hope it comes back again soon. So that's why I started working at All Zero a couple of years ago. But even before that, I was using All Zero, their products because, actually mostly because of the documentation. The product's great, but the documentation's just anyway. So like I've said, my name is Ben Dekrai, which means that my social media handle almost everywhere is also Ben Dekrai. Please get in touch any way you want to. I'm on LinkedIn and Twitter. I'm on Twitch and YouTube and just find me whichever way you prefer to communicate if you want to connect. My DMs are also open on Twitter, so we don't even need to be connected for you to send me private messages that way. It's a great way of getting in touch. Anyway, on with the show, let's talk about access control. There's predominantly two overarching areas that we want to think about when we talk about access control. There's a lot of subtleties around it, but there's two main things that I want to talk about. The first one is attribute-based access control, or ABAC, and the other one is role-based access control, or RBAC. You might have heard of these terms. Maybe you're even familiar with how they work, but let's have a look a little more deeply at what the differences are and what the features of each are. Let's have a look at ABAC first or attribute-based access control. When you come to looking at attributes, it's not just about the attribute of the user. It's about an attribute of many things. So the user, or in this case, the subject, is certainly an entity that we can assign attributes to. We also have actions. These are actions that take place. We have objects, which are the things we actually want to access, and then we have some more contextual information about the situation as a whole. So let's drill down a little bit further. As a subject, as a person, we might know which department you're in. Maybe you're in the HR department. Therefore, you might want to get access to personal records. Maybe you're working government and you have a certain clearance level to get access to certain bits of documentation. Or maybe it's a social media site and you can only use it if you're over a certain age or there are certain functionalities that are disabled if you're under a certain age. Or maybe you want to disable functionalities if you're over a certain age. I don't know. Whatever the reasons. Age is a perfectly acceptable and common attribute of a subject when you're looking at attribute-based access control. What kind of actions can we see? Although there are many we're probably mostly familiar with CRUD, create, read, update, and delete. Whenever we look at any kind of API interaction or developing models around data that we're storing in a database, these are the four actions that we do a lot of. So those are obvious actions that we can put attribute flags to in terms of connecting a subject to an object, what kind of action you want to perform. But then of course you can go at level further. They can be more process-related actions. Maybe you want to say whether or not somebody can take multiple bits of information and generate a report. Or maybe it's a workflow process where somebody is requesting and you will leave and you either can or cannot approve that. So it doesn't necessarily need to be about, the action doesn't need to describe exactly what you're doing to the data. It can be part of a process. So it gives you a bit more control, fine-grained control over the types of actions that you can define that can or cannot be done. Most importantly obviously is the object. This is the thing that we're stopping or allowing access to. The types of things that you might have in terms of attributes for an object are, well type is an important one. Is it medical records? That's obviously highly sensitive. Or is it public tweets? Probably less sensitive. Anybody can read a public tweet. Not everybody can read a medical record. What about clearance level? We've already defined that we could assign a clearance level to a subject or a person wanting to access it. But then we also need to store an attribute of clearance level against the object so that we have a point of comparison. And then you might have things like geographic regions or more location-based information. Perhaps you can only access things when you're in an office or from a certain country. Contextual is an interesting one. So this doesn't really relate to any of the first three but allows you to provide a bit more nuanced access control based on other things that might be going on. Typical examples of this would be something like time. Are you allowed to access things outside of office hours? Or maybe you're an accountant and you have access to your customer's accounting records and you do a quarterly return for them for them to submit to their tax office. You're only going to need access to their information for maybe a week or two right at the end of the quarter or probably actually just after the quarter. So maybe the first week or first two weeks of a quarter to access the previous quarters information. So you can do things at that level there. And then location. Obviously we know that we can lock objects down to certain locations. We need to know where the user is at a point in time. So if they're in the wrong country then they can't access information. So you can see there's a lot of stuff going on with attribute-based access control. And it allows us to really hone down and say we know that somebody wants to do an approval process. We know that they have the clearance level on the object that they want to do the approval process on. And we know that they're in the right geographic region to be able to do it. Therefore, we can grant them access. So you can think of attribute-based access control as a lot of if-then's stacked together that come out at the end of the day as a true or a false. It can be a very long chain sometimes as well. All right, let's move on to role-based access. This is gonna be a lot faster because it's not simpler. Essentially, we have three things that we consider. And whereas attribute-based access control had these four columns that were all quite independent of each other book could be linked. These are intrinsically linked. We have users, each user can have one or more roles and each role can have one or more permissions. A permission can also belong to one or more roles and a role can be assigned to one or more users. So there's all these many, many relationships but it's only between the two. Theoretically, it is possible in a lot of systems to have a user be granted permissions directly. Oftentimes, you probably want to do this because it makes maintenance a lot harder. If you know that a user is a member of a role, you can infer the permissions they have. If you want to change the permissions that all HR managers have, then rather than having to edit every user, you just edit the role. So by and large, you'll find that the role is not excluded out of these relationships. So an example of this might be Sarah. Sarah is a senior partner at a law firm. I've been watching suits a lot recently. So law is on my mind. And they recently, they didn't actually fire any of their staff. Their staff actually always left if any of you have watched suits. Just at the point now where Mike gets out of prison again. So, but Sarah is a senior partner and she is allowed to fire the associates. So this is a very easy to follow chain of permission. It's quite succinct. And at a glance, it's easy to see what's going on when you see these relationships next to each other. Whereas with an attribute-based access control, sometimes it takes a while to look at all the pieces and get them in your head and work out where the rules flow. So quick overview of comparison. I've kind of touched on these already. Attributes-based access control, it's really powerful. We saw in that final slide of the attribute-based access control how you can pick and choose each of the combinations of attributes that you want to satisfy in order to allow access or deny access depending on which way you're running this thing. It is complex though to define all of these things requires a lot of planning and a lot of thought because you could easily overcomplify overcomplexify the situation. But with that complexity comes really fine-grained access control. You can be really specific about one document because it's got a certain clearance level and it has to be within a certain region whereas anything else with that clearance level could be accessed from anywhere, for example. So it gives you a lot of control. Role-based access control gives you less control but it gives you that at the benefit of a lot of simplicity. It's also a lot faster. If you consider the whole if-then-else example that I gave in the attribute-based access control it can become a very long statement to calculate and imagine you're a computer and you've been told does Ben have access to this document? With role-based access control you can just look at the document and you know that the action is look at document so you can say does Ben have read permissions on this document? Well, he does if he's in a role that has read permission. So it's a fairly simple lookup whereas in attribute access control you've got to do all of these calculations and work out whether they're all true and then bring all of that together in one go to work out whether or not you have access or I have access to that document. Now computers can do that quickly but it's still going to be extra load so it doesn't scale as easily as role-based access control. So which one should you use? I love questions like this in conferences because invariably the answer is always both or either or it depends or there's no easy answer to this but generally when people ask me for recommendations on how to implement access control and which of these to go with I generally say look start with role-based access control because it's easy, it's simple it's easy for you to understand what's going on it's easy for you to train other people within your organization to understand how to configure the access control and to know who has which permissions. Now there will come a point potentially maybe there won't but in some situations there will come a point where role-based access control isn't enough for you it does just about all of it but then maybe you need a bit of extra refinement around some areas of control and for that you can then add access-based access sorry, attribute-based access control on top you can layer it so you can have all of these gateways gateways I guess in place to check whether or not the role satisfies access but then you can also layer on top of that yes they have access to edit on the condition that and then even start looking at some of the attributes as well. So it's a good way of minimizing the overall load remember RBAC is faster and easier to manage whereas A-BAC is more complex and is going to take generally more processing time to calculate all of these things so if you cannot calculate the A-BAC if you don't even satisfy the RBAC stuff that's going to save you time save you processing save you scalability all sorts of things like that all right demo time I think we are about 15 minutes in we have another 15 minutes so I want to go through and just show you an application that I've written in fact I'll just yeah I'll show you the live stuff I've got a couple of slides that kind of go into how I built it but I think it's probably easier just to dive straight in so let me make this smaller so I've designed this around the concept of a shopping system it's called the oldie shoppy because it's an old shop and I originally wrote this as a demo in React at the front end and I thought you know what I'll see whether I can repurpose it, redesign it really quickly in Flask I was trying to weigh up between using Flask or Django and I thought you know what I'll just go with the lightweight approach and I built this it's not necessarily perfect but you know I started this morning it's currently 11pm in Australia I have my coffee which has been keeping me awake and for any other Australians or Australian Australia files out there I have my packet of Tim Thames which is my chocolate sugar sauce to keep me going which is why I'm not asleep yet so we're good so far right so we've got this shopping site in here we've got three items which are pulled out of a database which are actually in a let me just refresh over here actually in an API that I'm running over on a different is this working properly of course it isn't normally when I get this demo it's in a single page app so you'd see it here but of course Flask is or Python is doing this on the server side so we can pull in our code over here and we can see down at the bottom that we've got an API over here listing on port 7000 and our Flask app over here listing on port 3000 so when we go to the website it's going to make a request to the API so don't kill me for the simplicity of the Python it's sometimes easier to just keep everything in one file we have our home page here which basically just goes off to the API and pulls in the JSON for the items endpoint and if we just open that up in a browser we can see here that we've got three items being returned we've got a burger, our pizza and our tea so we pull that out we pass that straight into the home.html and the home.html goes through and basically iterates through each of these items and prints out what we can see in the web page there which is basically the list of items what we want to do though is we want to be able to edit these items and add new items or rather delete and add so what I've done if we have a look over the server Python here this is following the standard quick start from Auth0 but it's not actually using any Auth0 SDKs it's using and if you've done any Auth stuff in Flask already you'll probably be familiar with the basically the Auth import here we're defining some variables which is configuring Auth to use the Auth0 identity server Auth obviously is a standardized protocol so it'll work against any identity provider that's Auth compliant then we're creating here an instance of the Auth object we're configuring it and then this is going to allow us to connect to or for the application to force us to log in and we can see down here when I hit the button here to admin that's going to take us to the admin route so let's have a look down here at admin essentially we've just got this requires Auth which is going to force Flask is going to force us to log in so when I hit the admin button over here you can see we're redirected to the login page this is hosted up here by Auth0 this will be whichever identity provider you're using if I log in now then I have access and we can see the page now the issue at the moment I'll be a little on the large side so if I hit the delete button here I'm going to get a you're not authorized to use this the delete function and if I try and add I don't know toast cost of dollar and it's yummy let's try that okay that's not going to work either I'm not authorized to create items so let's have a look at how goal-based access control works in Auth0 in order to give us these permissions we jump over to the Auth0 tab here we've got our applications I'm not going to go too much into depth on how to configure things for Auth0 I want you to get more of a concept of how the role-based access control works so you can apply it to whichever identity provider you're using obviously different systems that you use will have different interfaces but they'll probably have mostly the same kind of mechanism so in Auth0 here we've got two applications defined here's the single page app which is a different demo and here's a regular web app so this is where the configuration exists for allowing us to log into the Python app and then over here we've got our API the API definition allows us to set permissions so what permissions does the API want to know that the user has now remember when the user logs into the Python app Python is going to get an identity token which tells you about the user the name, email address is the email validated, things like that it's also going to get an access token and the access token in this case because we've linked the old shop here we've authorized this API to receive access tokens when logged into the Python app that access token can have information inside it that tells us about their permissions about the permissions of the user so let's create some of those permissions I'm just going to jump back over here because copying and pasting strings is a much better way of not getting typos so let's just jump up the API is actually written in Express but the theory is the same anyway so if we look at the middle way here we've got some permissions defined it's not actually in that one so look so in the router when we call the post endpoint for example then we check to see whether it has permissions create items and these here are actually just three strings so don't worry about how this works in Express you're not here to learn Express today but essentially what I want to do is I want to create, in this case because the Flask app only uses create and delete at the moment, we only need to add the create and delete so let's add a create permission so I'm going to call that create items description is create items I'm going to create another one called delete items the main reason I'm not doing update today is because I didn't get around to adding that into the app that I wrote this morning we'll add delete items so we now have the system permissions or scopes that can be requested or required by the API in order to allow things to happen so now we just need to jump down to user management roles we don't have any roles to find yet so I'm going to create a parole called editor and editor I'm now going to assign to some permissions remember a user has roles and roles have permissions so the editor has permissions I'm going to add permissions I need to select which API I'm giving these permissions for because there could be multiple APIs in this zero tenant but we've only got the one and I'm going to say editors can create items so we'll add that permission in let's go back to roles again and we'll create another role called admin and we'll add into this one both permissions because an admin can create and also delete items so we'll add that permission in there and now finally we need to jump into the users we'll find the user that we want to modify and in here we can, like I mentioned we can assign permissions directly but we're going to assign roles so if I assign a role here we have eight minutes what I'm going to do because we're almost at the end I'm just going to stop this for a second I'm going to log out and I want to show you in the React app what it looks like because we can actually look at the JSON web token if we dig in it's not working so this is a very similar application it's written in React I'm going to go to login over here which is going to take me to the same login page it's just logging into a different application before I hit enter I want to come in while I look at the network tab I'm going to log in here and then I'll filter by Auth0 so if you came along to the talk that I gave over the launch time networking session I was talking about how the Auth flows work essentially what's happened at this point is the single page app has made a request for the tokens in the same way as the Python app would do in the backend server to server so we can now see here that we have a response that gives us back our access token and our ID token so just very quickly let's have a look at what an access token looks like JWT.io JSON web tokens it's a system written by a colleague of mine I'm just going to paste this in I won't go if you want to find out more about JSON web tokens come and have a chat with me in the Auth0 booth afterwards or in the the adzulip and I'll tell you all about JSON web tokens but essentially what I just wanted to show you over here is there's no permission stuff in this access token at the moment so let's come in over here and I'm going to assign a role I'm going to give myself the editor role because I don't want to be able to delete but I do want to be able to create so now let's come in over here again and we'll log out and we'll log back in again the only reason I'm using the React app here at the moment is because I can pull the tokens out of the the network tab these are the exactly the same tokens that would end up in your Python apps so let's come down here and we'll look at this one let's copy that paste this in old one by the looks of it editor why didn't that work? Ah, live demos, you've got to love them let's try that one more time I'm going to clear this all right, let's log in ah, I remember why it doesn't work there's one thing that I've forgotten to do which is really simple and often overlooked so under APIs I just need to come in and edit my API again and enable down here role-based access control and I want to add the permissions into the access token that was the missing part of the puzzle all right, that's saved so now ah, I'm just going to go back and hit the login button again just to make sure that the process starts from the beginning now when we make a request here for the token we get this token and we will have permissions so we can see now the permissions array has come in this is what you would get in your Python app as well you get this permissions array in inside you can see the permissions that have been assigned to the role that have been assigned to my user so now if I come back in here and I go to the admin page now the Python app has a new token so I can come in here and try and delete but it's going to tell me I can't delete but if I try and add my toast back in for a dollar and it's yummy I create this item here now we can see that the item has been added because I have permission to do it so it's whichever identity provider you're using you should find that there's probably some kind of role-based access control built in one of the advantages here over doing it in say Flask login or the Django auth is that within your application you're defining the access control to that one application whereas because these permissions are going into the JSON web token whichever endpoint they're going to and in a service-oriented environment where you've got lots of systems that get touched on different platforms and different languages having the permissions wrapped up into the JSON web tokens means you don't need to re-implement your access control in each of the systems all you need to do is rely on the data that's in the JSON web token so let me just skip through this part here that I don't need to show you because that's the demo I just gave but I can thank you for your time I think we're pretty much three minutes left so I'm happy to take some questions I think the next session the keynote starts at half past or on the hour for the Indian time zone I'm happy to take questions just reach out to me on Zerik or in the booth as well if you want to ask questions after the fact and thank you for your time The keynote starts at 7 p.m. ISD so we can question any questions if you are Lovely There is one question in the chat if you want to take that up Is there a way to automate this process of assigning roles to users who sign in using social media accounts? Yes so obviously automating so far as you need to write the code for the automation component but essentially if I come in to where is it here? They've just changed the the menu system on the left there it is social so I can come in here you already saw when I logged in for the first time I could log in with Google I can add any number of other connections here to do any kind of social login what happens if I did log in with Google if we come back here under user management here you can see that the connection for the account that I created is username and password if I logged in with Google I'd get another user in here and the connection would be the Google social login mechanism so each user gets added into the system and each user will have its own ID within the Auth0 database they're represented in here even if the authority in this case Google for example is somewhere else so because of that because the users are actually stored in here that's where you would assign the user to a role now in terms of doing it automatically there is a management API and basically the management API is an API endpoint that you can hit that allows you to do everything that you can see in this management dashboard here so when you log into Auth0 here's where you do over configuration the management API allows you to programmatically do everything that can be done here in fact you can do more a little bit more but you can do more through the management API they can actually do through the dashboard so what you could do in your application is once the person's logged in obviously you're probably going to store that user ID in a database of your own if not there's a mini database against each user that you can use so there's this if you look at each user there's a app metadata and a user metadata area so you could store some information in here that allows you to know whether or not the roles have been set or you could just read the roles so conceptually what you could do is when the person's logged in in your application you can make a request via the management API to say give me all of Ben's roles and if Ben is not in the I've just joined role then put them in the I've just joined role so you could do that in your application the other thing you could do is you can put it into rules which again is in a different place now here we go so you can add new rules and I can create a rule that happens it's a little slow at the moment so there's an enriched profile there's a webhook, there's multi-factor I don't know if there's anything we could just click on as a baseline to start with but we could let's just do a search for group I could remember a directory group there isn't anything here right now but we could create an empty rule this is basically a JavaScript callback that gets the user that's just logged in the context which is basically information about how they logged in, where they've logged into and then the callback to carry on the chain of callbacks and in here you could say if the user's logged in have a look at the groups and assign them to a group if they're not already a member of group so that would be an easier place to put it because it's always going to run it gets run while the user's logging in you don't have to have it in your application but the API management would API API management API yeah the Auth0 management API gives you more flexibility you can do more there if you need to hope that answers your question okay good that answers your question is there any other questions I'm still going to be here for another line of minutes or so I'm happy to take your questions I'll also be back over the booth afterwards if you if you don't want to ask your questions right now I know some people don't want to ask questions in open so if you want to DM me on Twitter like I mentioned I'll just go back over here there's my Twitter handle again thank you for your time and I'll see you around one thing I'd just like to add though before I do go if you I'm doing another talk tomorrow on identity more generally on how login flows work so join me for that one that's over on one of the main stages Auth0 is also a sponsor of PyCon I'm really happy to to be able to do that as I mentioned I've been involved in in open source communities for a while I ran the open source developers conference in Australia for about 10 years and I love to give back to community so I'm really happy that Auth0 came on board and sponsored this event I'm loving the interactions I'm having with people I'd love you to come over to Zulu have a chat with me tell me about what you do from day to day there's also a couple of competitions that we're running so come over and you could be in the running for I think there's an AWS my AWS and Amazon gift card and some headphones so I'll see you over there thank you again spent it was a great talk and very informative okay I'm glad thank you for your talk tomorrow okay sweet thanks everyone have a great rest of the conference