Once someone has authenticated, they can access resources within the system. This is where authorization comes into play. We should authorize users to access only the resources they need to perform their jobs. In this lesson, we'll learn authorization in Atlas focusing on role based access control, common Atlas user roles, and demonstrate how to assign permissions to a new Atlas user. Authorization is the process of determining the resources that a user can access and actions they can take in the system. To do this, we use role based access control or RBAC. RBAC is a method for restricting system access to authorize users based on their roles. With RBAC, you can assign users to roles that have specific privileges, clearly defining the exact actions permitted, such as reading or writing data. It's similar to how employees in a company have job titles with defined responsibilities. For example, in a project team, you might have roles like developer, tester, and project manager. Each role has distinct permissions, ensuring that users can only perform the tasks relevant to their role. In MongoDB, role based access control is crucial in defining what actions users can take, such as viewing logs, managing clusters, or billing activities. But remember, in Atlas, we have Atlas users and database users, each with their own set of roles and privileges. Atlas users are part of the control plane. They're individuals who manage and configure the Atlas environment. Database users are part of the data plane. They interact directly with the databases themselves. For this lesson, we'll concentrate on Atlas users. We'll revisit database users later on. In Atlas, an organization is the top level entity where you manage groups of Atlas users and projects. Administrative tasks, billing, and user management take place within an Atlas organization. Atlas organizations consist of various roles, such as organization owner, billing admin, member, plus many more. Beyond the organizational level roles and privileges, we have project level roles and privileges. Projects inherit overarching privileges from the organization, but give project users the ability to tailor an environment for a specific application. Inside each organization, you could have multiple projects, and each project can have its own set of roles and privileges. Projects have various roles, such as project owner, project data access admin, project data access read only, and project cluster admin. While this is not an exhaustive list, it gives you a sense of the kinds of built in roles available. If you want a more comprehensive list of all the built in roles, you can check out the Atlas documentation. Now let's take a moment to examine each of these roles to see the privileges they have. Starting with the organization owner, which manages everything from organization settings to billing, as well as the users and projects within, providing full administrative control. Another role is the organization billing admin, who is focused specifically on financial matters, managing billing details and payment methods, but they don't have the authority to change other settings or projects. Meanwhile, an organization member has a more limited scope of access. They can view organization details, but their administrative privileges are more restricted. This means they can't create, modify, or delete clusters, nor can they manage user access. Next, let's shift our attention to the project roles to see what they are able to do. The project owner has full access to manage the project. This means you can handle everything from configuration to user management. You have the power to create, modify, and delete clusters, as well as set up monitoring alerts and backups. You can also establish integrations, access logs and auditing tools, and add database users to the project. In addition to these responsibilities, the Project Owner role provides access to tools like Data Explorer, allowing read and write operations and observability tools such as the Query Profiler, which help users analyze data efficiently. You can choose to disable these tools through organizational settings if needed. Similarly, the Project Data Access admin grants full access to Data Explorer, allowing users to manage databases, collections, indexes, and documents within the UI. Additionally, it provides access to observability tools such as the performance advisor, query profiler, and real time performance panel. On the other hand, the project data access read only role is limited to viewing databases, collections, and indexes via data explorer and observability tools. This can view documents within the UI tools, but not via the admin API. Project data access roles are designed to offer different levels of access to the data explorer, enabling users to receive permissions customized to their specific requirements. This ensures that each team member has the appropriate level of access needed for their role. Beyond the data explorer, certain rules also focus on managing cluster operations. For instance, the project cluster admin has the ability to pause, edit, and resume clusters within the project. They can't create new clusters since that goes beyond their permissions. In summary, organization roles pertain to the management and high level administration of the entire Atlas organization, encompassing all its users and projects. These roles focus on broad responsibilities, like billing and user access management, across the organization. On the other hand, project roles are specific to individual projects and center around managing resources and activities within a particular environment. It's important to note that these roles are hierarchical. Higher level roles in the organization have overarching permissions that can affect multiple projects, while project specific roles are more focused and restricted in scope. That was a lot of information, but let's shift our attention to the practical side of things. Adding a user to our Atlas organization and assigning both organization and project roles. This is a key step in ensuring that users have the appropriate permissions tailored to their responsibilities. For this, we'll be using the Atlas Admin API, which requires you to generate API keys prior to using it. Next, we need to set our header information. We'll specify the API version to ensure the response is compatible with our expectations. Details can be found in the Atlas Admin API documentation. Additionally, we'll indicate the format of the data we're sending. After that, we'll specify a post request to the org user's endpoint. For this, we need to provide the org ID that we want to invite the user to. Next, we add a payload with the information needed to invite a user. We start with the rules we want to grant the user for both the organization and project. You may have noticed that it says group instead of project. For the Admin API, projects are known as groups. We have to specify the ID of the group we want the user to have access to, along with their role within the group. Here, we're making this user a cluster admin on the project listed here. After that, we assign an organization role to the user. This user will be assigned to member status. This means they're a part of the organization, but they can only view the projects they've been added to. Finally, we provide a username, which needs to be a valid email address. Once we run this, it sends an email to the user with an invitation to the organization. If the user doesn't have an account, they'll be guided through the account creation process. Once complete, they'll be added to the organization. Awesome work. Let's briefly recap what we learned. We started by understanding the importance of authorization and safeguarding resources by providing users only the access they need to perform their duties. Role based access control, RBAC, allows us to do this by granting users privileges and permissions based on their role. Atlas comes with many built in roles we can leverage for RBAC. And in this video, we focused on the Atlas user. At the organization level, built in roles can manage users, billing, and set organization wide policies. At the project level, project roles can adapt the environment for specific applications by managing users, cluster settings, and monitoring performance. Finally, we showed you how to add a user to an Atlas organization and specific project with the Atlas admin API.