User Identities and Authentication

0:00Hi, Sean here and welcome to this skill where we're going to be taking our first look at the basics of user identities and authentication from the point of view of a GitHub admin. Now, because this is the first skill in this course, what we're going to need to do first is get ourselves set up for all of the demonstrations that will follow. Again, I highly recommend that you follow along with me here. Ideally, you won't need to put in any of your credit card information, but that seems to change on a fairly regular basis, whether they let you do a truly free trial or a free trial where you get 30 days free, but then have to pay for the other 11 months.

0:37Kind of depends on the exact timing that you're watching this, but whatever the case, if you want to follow along with me in this course, I would highly recommend that you, you know, walk through the steps that I'm about to show you here because, well, that'll give you the basic setup that I'll be using. So the first thing that we're going to need to do here is we're going to create two GitHub accounts. All right. So I'm going to start here. This is just literally plain old github.com. Chances are you probably already have a GitHub account. So if you really want to use that as one of the accounts here, um, feel free to go ahead and do so. I was a little bit hesitant to use my own personal account here, just because I want to keep the setup as clean as possible as, as close to what you're likely to have as possible. And so what I'm going to do is I'm going to click this sign up button in the top right-hand corner, and that will take us directly to this, uh, create your free account screen where we're going to need to put in our email address and password and username.

1:38Now, honestly, from a demonstration point of view, this is probably one of the more annoying demonstrations that exists because, you know, you need to either screen share your email address or create a new email address, which Gmail is not real, um, keen on doing. And so what I'm going to do here is I'm just going to skip over this part. I'm sure you know how to do this already, and I'll see you on the other side. And there we go. So here's what I did just so that you're aware of the current setup that I have. I created this new account called Sean WCBT Nuggets. That's my username here. And then up here in the very top right-hand corner, if you expand your little profile dropdown, you can use what they call the account switcher, very apt name. And I have this other account that I set up actually about three years ago that I forgot about using another email address. And, uh, so I'm just going to use this one as the other account. So the next thing that we need to do, and I'm going to use my new shiny account for this is I'm going to create an organization. Now we'll be talking a lot about organizations in this course, but for now, literally, it's just going to be a container that we'll use for demonstrations. So I'm going to open this up. We're going to go down to organizations. And now that we've done this,

2:55we're going to create a new organization by clicking new organization up here in the top right-hand corner. And now that we've done that, we're going to start off by creating a free organization. We might need to upgrade again, um, kind of depends on how the GitHub marketing and pricing strategies have evolved since I've recorded this, but for now, I'm just going to click on, create a free organization. And what we're going to do here is we're going to say that this organization for now belongs to my personal account. Now, this is the point at which you would put in a business or institution. If you're setting this one up for, well, a business or institution, but because that is not my case, I'm going to enter that in. And in order for this to work, we're also going to need to enter an organization name. So I'm just going to open that one up here. We'll call this something like Sean's software ink, something like that, right?

3:51You can feel free to name it, whatever you want. You do not have to use my name. In fact, you probably shouldn't because well, unless your name is also Sean, it doesn't make a whole lot of sense. And for the contact email, you're going to need to fill this out. I'm going to fill this out, but I'm going to skip over this. And once you filled it out and checked the little checkbox that says, I hereby agree to blah, blah, blah, blah, blah. You should be able to click on next, which will bring you to this page where it's going to ask you to add organization members. Now we're going to talk about this in a little bit more detail. Uh, but for now, we're just going to skip this step and that will bring us to the organization. Now, the last thing that we're going to do here is there are a lot of features that require you to have, uh, some sort of enterprise subscription. And just to keep my demos as straightforward as possible in this course, I'm going to set that up now. And so here's how that works. We're just going to go back up to the top right-hand corner here. We're going to go down and right underneath organizations, we're going to click on enterprises and we're going to click on this little start free for 30 days button. Hopefully that still exists for you by the time you watch this video.

4:58And this actually brings us to one of the first things that I wanted to talk about in this skill, which is the difference between having an enterprise that uses personal accounts and an enterprise that uses what are known as managed users for now, just to finish our setup though, we're going to say, get started with personal accounts. All right. So we're just going to have to fill out all of this information here. So I'm going to call this enterprise, something like Sean's software enterprise. Notice that that will also automatically generate this enterprise URL slug down below Sean software enterprise for industry. Here's what we're going to do. We're going to select, um, let's see your software and internet. Perfect number of employees. We're going to say zero to 50, which is absolutely true. And then for organization, we're going to choose the one that we just created here. Sean's software Inc. And now for contact information, I'm going to skip over this part here. Once again, you're obviously going to fill that in with your own information, check these things down at the bottom, except for probably this targeted advertising one, you can leave that blank. And then you're going to click create enterprise. And there we go. Now it may ask you in the process of doing all of this to verify your email. So if you see that, just go in and verify your email. It's pretty simple. All right. So that should be all of the

6:17major setup that we'll need for now. So just to review what we have here so far, we have two accounts that I've created. One is Sean WCBT nuggets. And this is the account under which we created that organization and the enterprise that we just saw. But there's also this other account that we'll be using, which is just another personal account that we'll be using for demonstration purposes. And notice that when we switch to that account, looking at this enterprise, because this other account isn't part of the enterprise, it shows up as a 404 page here.

6:48We'll talk about that in a little bit more detail later, but anyway, that's the four things that we have here so far, two personal accounts, one of which owns an organization and an enterprise. So now that we have all of that set up, we can move on to more interesting things like user identities and authentication in GitHub.

0:00All right. Well, now that we've created two personal accounts, one organization and one enterprise that we're going to be using for the rest of this course, the next thing that I want to do is talk about our first topic, which is the difference between personal accounts and managed users. This is a very important distinction to make as a GitHub admin. And, um, so let's just talk about what this looks like. So first of all, you may remember that when we created this enterprise and you can see this flow again, if you go up to the top and click new enterprise, okay, there we go. Remember that we selected get started with personal accounts. Now, without a doubt, this is the most common approach to use when creating a GitHub enterprise, but notice that there's another option that we didn't select here as well, which is to use something called managed users. Now you'll hear these referred to sometimes as E M U's right. Enterprise managed users that is. And this can be a great way to quickly create lots of accounts that your company has lots of control over on GitHub. But again, it's not the most common approach. We'll talk about what it looks like in more detail shortly, but this is the first thing that I wanted to point out is that we explicitly selected the personal accounts

1:17approach for our enterprise. Now, the interesting thing about this is that there is no way to mix the account types in your enterprise. So you can't have an enterprise that sort of straddles between these two and uses some personal accounts and some managed users. Uh, that's just not how GitHub enterprise is designed. So anyway, if we go back to our enterprise here again, remembering that we chose the personal accounts option, what this means is that when we want to add users here, right, let's say that we just hired 10 new developers and we want to add them to our enterprise so that they can start developing and contributing to projects, things like that.

1:57What we would do is we would have each of those developers create their own account. Here's how I'm going to draw this. I'm going to draw each of the developers like this, and I'll just draw three here for the time being. And they're going to create their own account, which I'll draw as this little like sort of ID card. This is their account. All right. And then what we're going to do is our enterprise is going to invite their accounts to join, right? So this is our enterprise. We're going to say, all right, Hey, these people already have accounts. Let's invite them to our enterprise and give them access to contribute to our projects, things like that. All right. So just to demonstrate what this looks like from the point of view of both a GitHub admin and a person being invited, let's just walk through that process real quick. What we're going to do here is we're going to say, invite enterprise members. We're going to click on that. And then we're going to search for the other account that we created. So if you created two accounts here, remember that I'm using this Sean WCBT nuggets account here as the owner of the organization and enterprise, we're going to invite my other account, the just plain old Sean Wassell account to be a member of this enterprise. So here's what this is going to look like. We're going to say, invite member up

3:13here in the top right-hand corner. We're going to say, uh, down here, there's this little search bar. So we're going to search by username, which is just plain old Sean Wassell. There we go. And there's that account in case you're wondering what you're looking at there. That's me with a rather long hair and a very long beard. Um, just kind of a humorous photo there. Anyway, let's select that and we're going to click invite. So again, what just happened there is that account, right? That Sean Wassell account exists outside this enterprise. Someone else created it.

3:46In my case, I created it, I think about three years ago, and it's just been sitting there, not part of this enterprise for that whole time. And that as we'll see is the major difference between personal accounts and managed users. I'll get to that in more detail in just a minute here, but first let's take a look at this process from the point of view of the user who was invited to the enterprise. What we're going to do is we're going to switch accounts over to this regular Sean Wassell account. And once again, because we're on that, uh, Sean software enterprise page, which this account is not yet part of the account needs to actually, the person needs to actually accept that invite before they'll be able to see this. We see this four Oh four page. And so what we're going to do here is just go home where we should see our invite. You may have to search around for this a little bit. I believe it's actually under, if you go to enterprises here, you should see that there's this invitation sitting here and there's a button next to it that says accept. All right. So if we accept this from this personal account that was previously entirely separate from the enterprise, what that means is that this person is now going to have access to some degree. We'll talk about that in much more detail throughout this course as well.

5:01Um, but this person is going to have some access to that enterprise. So let's click accept. And here we are. We're at the enterprise homepage. Now an enterprise, by the way, I probably should discuss this before we go any further. GitHub has sort of like a hierarchy of constructs that are used to manage projects and ownership and access, things like that. At the very top of this hierarchy is something called an enterprise. This is what we created there before. You can kind of think of an enterprise as like a family of companies, right? That's typically how that an upside forgot the extra R in their enterprise. Kind of weird having that RPR next to each other there. It's just a hard thing to write for some reason while I'm talking. But anyway, this is kind of like a family of companies once again. So presumably, and I don't know if this is true or not, there's an alphabet enterprise out there under which is a Google organization.

5:58Again, I don't know if that's true, but that's the basic idea of how that works. So underneath an enterprise, as we already saw is an organization. This represents typically a single company. And then under that organization, we have typically a series of projects, repos, things like that, that the company is working on. All right. So if you're confused about the difference between an enterprise and an organization, really, you can think of an enterprise as just a container for multiple organizations. And in many ways, that's all it is. So anyway, now that we've accepted that invitation from the point of view of this Sean Wassell account, we can go to the organizations tab and sure enough, we can see Sean software Inc. And if we open that up, we see that it says this organization has no public repositories. Now we'll be fixing that at some point in the near future. But the point being that we can now view this enterprise and the organizations that it contains. And if there were repositories in here, we would be able to access those as well. All right. So anyway, going back to what I was saying at the beginning of this video, the approach that we just saw acted out there is the approach of having the developers themselves create their own personal accounts

7:15that will outlive their employment typically, and then inviting those accounts to the enterprise, right? So you create your enterprise, right? The developers, as I drew out earlier, create their accounts, which belong to them, right? They could be fired tomorrow. And they would still have those accounts, although those accounts would typically no longer have access to the enterprise. But then we just send invites to those specific accounts, giving them access to the enterprise, the organizations, the repos within reason, of course. So this differs quite a bit from the other approach that I mentioned, which is the approach of using something called managed users. Okay. Now, the interesting thing about managed users is you probably already have some experience with this, just perhaps not with GitHub. So for example, if you have a company email where it's like, you know, your name, Sean, at whatever company, XYZ Corp.com, for example, this is typically a managed account, right? The organization, the company that you work for creates it for you, and it belongs to the organization. They just allow you to log in

8:35and use it, right? And if, so to speak, you decide to move on to other opportunities, then you leave that account behind when your employment ends, right? In other words, it's linked to the enterprise itself. Now, in the case of GitHub, let me just kind of try and illustrate what this looks like. The enterprise itself is going to own those accounts, right? So here's the accounts that belonged to the users over here on the left-hand side.

9:06The accounts belong to the organization under the managed users way of doing things. And these three devs, when they get hired, they're merely given access to those accounts, which in turn give them access to the enterprise and all that it contains. All right. So as you can see already, there is a very subtle, but very important difference between these two things. And to put it as simply as possible, it's a matter of ownership, right? Does the enterprise own the accounts that people use in order to, you know, contribute to repos, things like that, or do the employees own those accounts? It's as simple as that. Now, one last thing that I wanted to say about the managed users scheme here is that typically these accounts won't be set up in GitHub. They'll be set up using something called an IDP, typically abbreviated like that with a lowercase D. I don't really know why that is, but this stands for identity provider.

10:04And basically an identity provider is just a centralized place for creating and managing employee accounts. So typically if your organization is going to be using this enterprise managed user approach, they'll already be using it for a lot of other things as well. So if you have, you know, if you're using a project management tool like Jira, typically your employer will own the account that you use for that as well. All right. So anyway, hopefully this video has helped you to understand the difference between personal accounts and managed user accounts in GitHub.

10:36And as I've already said, personal accounts are still the most common approach for companies to take with this. And so that's really the main approach that we're going to be taking in this course as well. Although I will do a few demonstrations with managed users later on in the course, just for the sake of completeness.

0:00All right, well, now that we're familiar with the high-level difference between personal accounts and managed user accounts, the next thing that I wanna do is go a little bit deeper into the details of these two accounts and what can and can't be done with them. Because, you know, obviously in the previous video, I said that the main difference is that the enterprise owns managed user accounts, whereas the individual users own personal accounts. This fact has a lot of interesting implications for people using these accounts on GitHub.

0:35So let's just kind of start by listing out the things that we already know about these. So we're gonna say personal account, I'm just gonna abbreviate that as PA here, and then we'll have enterprise account, which will be EA. All right, so the first thing that we've already seen is the difference in who creates this. So I'll write created by. So as we've already seen, personal accounts are created by the individual, right? So the employee, the user, whatever you wanna call them.

1:06Whereas enterprise accounts are created by the enterprise or company or whatever you wanna call it, typically via an identity provider, right? So I'm gonna write that like this. We'll say enterprise. Let me try writing that again, enterprise. And then I'll write this as via IDP, just like we talked about in the previous video. All right, now we saw that in addition to the initial creator, the account continued to be controlled by that person or entity as well, right?

1:42So I'm gonna just add that to this created by thing. We'll say created by, controlled by. So in both of these cases, for personal accounts and enterprise accounts, the person who controls that account, right? The person who maintains ownership over that account, even after the employee no longer works for that company anymore is whoever created it, right? So with personal accounts, the account follows the employee even after they leave the company.

2:14With enterprise accounts, the account stays with the company and typically the company will just kind of deactivate that account when the employee leaves, but they'll still have access to all of the information that it contains, all right? So we already know that, but as I said, there's a lot of other implications of this that are important to know about as a GitHub admin. All right, so the next thing that we'll talk about here is how authentication is handled in both of these cases. That is a hard word to write while I'm talking.

2:45So there we go, authentication. In the case of a personal account, the authentication is handled just by GitHub's credentials, right? So as we already saw with a personal account, the user will have a username and password that they'll use to log in. Sometimes they can log in using their personal Gmail account. You get the idea. Now, in this case, the enterprise can require that they use things like two-factor auth, but the authentication itself is still handled through GitHub.

3:19Now, on the enterprise side of things, if you're using managed users, and actually, let me just write that up here, managed users, or EMUs is the acronym that you'll typically see with that as we talked about earlier. In this case, authentication will usually be handled through the enterprise's IDP. So let's imagine that you have a managed user account and you wanna log into GitHub. Well, instead of putting in your GitHub credentials like you would with a personal account, GitHub's gonna send you to your company's IDP.

3:53So for example, Microsoft Entra ID is a very common one to use with GitHub because they're owned by the same company. That is Microsoft. And you would log in there and it would send you back to GitHub once you do that. So it's a much more centralized solution. All right, so beyond authentication, let's talk about profile, right? In other words, who manages the information that's in that profile? In the case of personal accounts, it's managed by the user, right? So the user manages their email address, any other information about themselves on their profile.

4:26They can manage their profile picture, things like that. Whereas with managed user accounts, typically this is the enterprise and or the IDP that does this, all right? So enterprise slash IDP, and there you have it. All right, so moving on, the next thing that we come to here is an interesting set of abilities that only personal accounts have and that enterprise accounts purposely do not have. Now, as you'll see, the common factor between all of these abilities is that they allow the user through that account to do things outside the enterprise, right?

5:05So let's start off by taking a look at how public repositories are handled here. All right, so if you've been using GitHub primarily through a personal account, it might seem kind of obvious to you that a personal account is able to create and contribute to a public repository. And yet over here on the enterprise side of things, if you're using a managed user account, you can't, right? In other words, the access of a managed user account is typically restricted to the enterprise itself.

5:43All right, so I'm just gonna write no here, but what this means is that managed users cannot create public repositories. They can't contribute to public repositories. And once again, that's intentional. Typically, when you use managed user accounts, it's because the organization has some highly proprietary code or other content that they want strict control over. All right, now this also means, this may be synonymous in many cases, but if you want to contribute to open source projects, let's say, then personal accounts are able to do this, whereas managed user accounts are not able to.

6:23Now this can be inconvenient at times, right? After all, it is fairly common for employees to contribute to open source projects with what you might call ulterior motives. That is because the organization needs a particular change or fix to an open source project. But once again, on the managed user side of things, this is all done with the ultimate goal of tight control. In other words, whatever their employee does outside that organization, it cannot be through that account, okay?

6:53So anyway, hopefully this helps you to understand some of the broader consequences of choosing personal accounts versus managed user accounts. And so the last thing that I wanna do is just kind of summarize when you would use either one of these. So the typically used case for personal accounts here is just as a general individual GitHub identity for personal and professional work, right? So I'm gonna just simplify what I said there a little bit.

7:24We'll just say something like GitHub identity for personal and professional work, right? So in other words, if your company is using personal accounts, it's just kind of understood that your employees, through their personal accounts, are going to have a life outside of work, so to speak, right? They might be working on their own GitHub repos, they might be contributing to open source projects, and they're doing all of that through the same account that they're using to contribute to your company or enterprise.

7:55Now, many companies are fine with this, right? Especially in the software startup world, this is a fairly common thing to see. But in more controlled environments, that's when you end up with this whole managed user account thing. And this, just to sum up what this is and when you would use it, we'll write this as a company controlled identity for tightly managed environments, right? That's really the main difference here in the use cases between personal accounts and managed users.

8:33So anyway, hopefully this video has helped you understand in a lot more detail the differences between personal accounts and managed user accounts.

0:00All right. Well, now that we've taken an in-depth look at the different types of users that are available in GitHub, right, that is a decision that you have to make very early on, which is why I spent so much time talking about it. Because again, you can't change an enterprise from one to the other once you've made that decision and started adding users. And so the next thing that I want to do here is I want to take a first look at the idea of working with roles across the different constructs that we've seen so far, right? The fact is that enterprises, as well as the organizations that they contain, as well as the repos that those contain, all have this idea of roles as a way of controlling who can do what in a particular construct, right? In a particular enterprise, in a particular organization, in a particular repo. And by the way, when I say roles, I'm talking about R-O-L-E-S, lest you haven't had lunch yet and you're hearing me say roles.

1:01That's not the roles I'm talking about. So anyway, the interesting thing about this, and probably the most important thing to grasp at this point, is that each of the levels that we've seen so far has its own roles that can be assigned to members of it. So let me just show you what I mean by that. If we open up our enterprise that we created, and here, let's just go to invite owners. It doesn't really matter what you click on there. The point is to get to this screen with the menu over here on the left-hand side. And what you'll see there is, there's this little dropdown called enterprise roles. And as you can see, there are two menus here, one for role management, one for role assignments. Now we're going to get into much more detail on exactly how these things work a little later in the course. But for now, what I wanted to point out is that the enterprise itself, the highest level of that hierarchy that we talked about in previous videos, has its own roles that control who's allowed to do what in the enterprise. In other words, you're not just going to be sharing your username and password in order to allow everyone at your organization to log into this same thing and perform different

2:18tasks on the enterprise. Please, please do not do that. And so anyway, by managing roles, you can control, as I said, who is allowed to do what in the enterprise, right? So who's allowed to add other users to the enterprise? Who's allowed to add new organizations? Who's allowed to modify the basic information of the enterprise, like the enterprise's name and other info? All of that is determined by these roles. Now, the other thing about this, right, going down another level is that the organizations that an enterprise contains each have their own roles that control who's allowed to do what in a particular organization. Now, for me, this thing already has a checkmark just because I have clicked on it before. Just ignore that. You probably won't see that yourself. You probably also won't see this little congratulations, you've completed a task pop up with the octocat with a jetpack on. Anyway, what you'll see here is over here again on the left hand side, there's a little drop down for organization roles. And the important thing to understand is that these are independent, at least in large part, from the roles of the organization that contains it, right? So as you can see, if you click on role management here, there's a pretty

3:37comprehensive list of all of the things that these roles that a given role can control. All right, so for example, there's this all repository read role that basically just gives a user who has it the ability to access, as you can see from this little description under here, all of the repositories in the organization in a read only way, right? So they'll be able to see what repos the organization contains, what code is in them, information about the repos, etc. But they won't be able to make any changes to it. And obviously, you know, if you just read through these, you'll see that there are plenty of other things that you can control. Once again, we're going to go into much more detail on this later in the course. So going down another level, right, we've seen that enterprises have their own roles, organizations in an enterprise have their own roles. And so the repos in an organization also have their own roles. So let's just open up a repo here. Now that we've opened up the organization we created there, we're going to go to repositories. And we actually don't have one of these yet. So let's just click a new repository. And we'll call this something like my first repo. And then what we'll do next is we'll just leave everything else as is. And

4:55we're going to say create repository, just for the sake of being able to look at the roles for this repo. So once again, let's just go into the settings for this repo. If you click on settings there. And sure enough, if you take a look at the left hand side here, it's a little bit different than what we've seen with enterprises and organizations. But we do still have this team and member roles thing, which allows us much more fine grained control over who's allowed to do what on a particular repo. All right. So anyway, the point of all of this, and really the main takeaway at this point is that GitHub gives us some amazingly flexible tools for making sure that exactly the right people are able to do exactly the right things across every level of our enterprise, right? Again, at the enterprise level, at the organization level, at the repo level.

5:51And while this is something that we'll be getting into in more detail later, this level of flexibility that GitHub gives us truly is necessary in many cases, right? And in order to understand why this is, let's just jump back to my whiteboard here. And let's imagine that we have an enterprise like we currently have. I'm just going to write that as E. And then maybe this organization or sorry, maybe this enterprise has multiple organizations here, right? We'll just call those O1 and O2. And then maybe each of these organizations has some repos, right? So we'll have R1 and R2 under, oops, why did I write R3? Let's try that again. All right, R1 and R2 under O1. And then we'll have R3 and R4 under O2, right? And what this separation of concerns you might say allows us to do is have different users take completely different roles at different levels of this hierarchy. And not only at different levels, but in different specific instances in this hierarchy, right? So in other words, this person here, we'll just call this these person A, B, and C. Person A could in theory be the owner of the enterprise, but this does not mean that

7:09they have to then be the admin of these organizations and admin of all of these repos, right? They can make person B here be, let's say, the admin of repos 1 and 3, right? We'll just write admin there. And they can make person C be the admin of these two organizations here. This is getting to be kind of a convoluted chart, but the point being, the fact that we have different levels of roles for enterprises, organizations, and repos allows us to achieve this kind of complexity if we need it. And in many organizations, this is necessary.

0:00All right, well, in this skill, we've set up enterprises, organizations, and repos, and we've also created some users. And so the last thing that we need to do, which I'm gonna give you as a challenge here, once I've kind of shown you exactly what this involves, is we need to actually associate the other user here, right? Remember that this account is the owner of this enterprise, but the other user that we set up here earlier in the skill isn't yet associated with the organization and repo that we set up.

0:37So for example, right, if we switch accounts and go back to this personal account here that we added to the enterprise, what we'll see is that while this person is able to see the enterprise, because they are a member of that, they're not actually able to see any of the organizations in the enterprise. Well, they're able to see it as a list, but if we go into the organization, we're not actually able to see any information about the organization, right? And that's because this user isn't yet a member of this organization.

1:08And the same thing is true of the repos, right? Because this person hasn't explicitly been added to any of these repos, they have basically no permissions whatsoever with regards to those repos, right? They're not even able to see that they exist. And so that is your challenge here, is going back to the other account, right? The enterprise owner that we created the organization and repo in this enterprise with, we're gonna need to add that user to the organization and also to the repo that we created.

1:45Now, I'll kind of point you in the right direction here just to make sure you don't get totally lost with this. But first, let's go back to our enterprise. And what you're gonna need to do here is inside this enterprise, you can click Invite Owners. This also allows you to add other people in other capacities. I don't know why they just say Invite Owners, because again, you can do other things too. What you'll see here is if we go to Members, that person is already a member of this enterprise. But if you go into the organization that we created, you'll find that that's not the case, right?

2:18If we go to Organizations and go to Sean Software Inc here, what you'll see is that there's this Invite Your First Member link, and that will take you to the place where you can actually add that other user as a member. And you'll find the same thing under Repositories here. If you go to Repositories, we'll open up my first repo that we created here. And then if we go to Manage Access right here up at the top, what we'll see is that you can add people here by clicking this Add People button.

2:49All right, so anyway, that is your challenge here, is to walk through what I just showed you and add that other user to the organization and the repo. So anyway, feel free to give this about five to 10 minutes to complete, and once you've given it a try, you can move on to the next video where I'll walk you through the solution. So best of luck, and I'll see you in the next video.

0:00All right, well hopefully you gave this challenge a try, so let's take a look at the solution. So the first thing that we're gonna do is we're gonna go back to the organization here, Sean Software Inc., I'm gonna click on that, and as I said, we're gonna go to invite your first member, and we're gonna add that other account to this organization. So here's what this'll look like. We're gonna say invite member, and what we have to do is basically just search by the username. So I'm gonna say Sean LaSalle here. Make sure to search by your own username. Verify with that icon there.

0:31And we're gonna click invite. Do make sure that you're inviting the right person there. If your name is something a little bit more common, like, I don't know, John Smith, definitely be careful. But anyway, we're gonna click invite there, and we're gonna say that we wanna invite this person as a member. If we were to invite this person as an owner, that gives them full administrative rights, as you can see in this little blurb here, to the organization, which is not what we wanna do here. We already have one owner, and that's us.

1:02That's this account, anyway. So we're gonna click send invitation, and now that we've done that, again, we get this little, you've completed a task pad on the back up here, virtual pad on the back, that is. And so the next thing that we need to do is we need to go and add this person to the repo. So if we click on repositories here and go into my first repo, what we'll see, if we go to manage access, is you may have noticed this message up here that says members of any organization belonging to Sean Software Enterprise can see this repository.

1:35Now that's kind of interesting, because that suggests that we don't actually need to add that other user directly to this repo in order for them to have access to it. And that's also a very easy thing to test, so let's go test this, shall we? What I'm gonna do is I'm gonna jump back to this other user. We're gonna switch accounts, and well, first of all, we get this 404 page, because that person's, this user, even if they're able to access that repo, is not able to access the settings, and especially the access part of the settings.

2:07That's something that only admins can typically do. So what we're gonna do is we're gonna go back to the homepage, and we're gonna go up here and go to organizations, okay? So we need to accept that invite to Sean's Software Inc. So we're gonna say accept there. We're gonna say join. And sure enough, with no additional access given, we can now access this MyFirstRepo. Now, you might be wondering why did this user not show up in that access list when we were looking at the repo from the other account, right?

2:41Well, the thing to understand is that if we go back to that account now, let's just open the admin account up, and we're gonna go back to our repo here, what we'll see now is it says all two Sean's Software Enterprise members, grammatically a little bit off there, but anyway, all two Sean's Software Enterprise members can access this repository, right? Now, we can change that as the default behavior, but basically that means that because that person is a member of that organization, they automatically have read access to all repos in that organization.

3:17Now, if we wanna allow them to contribute, that's a different thing, but well, you get the idea. All right, so whether you notice that or whether you just went straight in and added that person directly, doesn't really matter too much, right? This would be how we add more complex roles, right, or more, let me rephrase, this would be how we add more privileged roles to a particular user, so as we can see, read is marked as the base role here, meaning that that user already has that, but you can also give them more privileged roles like triage, write, maintain, or you can make them an admin if you really wanted to.

3:52I'm not going to do that, but well, if you went in there and added that person directly, that's totally fine as well. All right, so anyway, that was the solution walkthrough. All right, so hopefully this helped solidify what we've learned so far about enterprises, organizations, and repos, and the corresponding roles that allow users different types of access to those entities.