How to Manage Access to Projects and Git Repositories – Demystifying Space Permissions

Maarten Balliauw

As an all-in-one solution for software teams, JetBrains Space brings a large set of functionalities together in one place. You can communicate in chats and internal blog posts and teams can build and deliver software, with documents, issue tracking, Git repositories, automation to handle Continuous Integration (CI) needs, package repositories, and more.

How do you control who can log in? How do you manage permissions in Space, and give your teams access to the information and tools they need? In this blog post, let’s look at how you can control access to your Space organization, projects, and Git repositories.

Username/Password or Single Sign-On

First things first: let’s start with authentication and logging into Space. By default, users can authenticate with a username/password combination, and optionally enable Two-Factor Authentication (2FA).

Many teams and organizations already have an authentication solution in place. Some may be using Active Directory or Azure Active Directory, others may be using Google Auth. Space supports a number of third-party authentication mechanisms that you can enable.

As a Space administrator, you can configure authentication modules under Administration | Auth Modules.

You can enforce logging in using an external authentication module. Once you have one or more of them configured, you can disable the built-in username/password authentication.

Authentication modules generally do not import user accounts: Space only validates the user when logging in. When enabled, user accounts can be created upon the first successful login, so that anyone in your organization can use Space.

Another element that is not imported from a third-party authentication module is permissions and roles. Regardless of whether you are using the built-in username/password authentication or an external system, Space permissions will have to be managed in Space.

Space Permissions and Self-Organized Teams

After creating and setting up a Space organization, you will be granted the System Admin role. This role is typically granted to users in charge of administering your Space instance, which can be people from IT or HR. It cannot be changed, but you can create a new role with custom permissions if needed.

User permissions in Space are handled through roles that fall into these categories:

• Basic permissions – Permissions that every user in the organization has.
• Project-specific permissions – Permissions that are valid within a specific project.
• Team-specific permissions – Permissions that are valid within a specific team.
• Global permissions – Permissions that are valid within the entire organization.

The System Admin role is a global permission, which means it is valid throughout the entire organization. The Project Member role is a project-specific permission, which means it applies within the scope of a single project, and can be different for every project.

All users in Space are granted the Self and Member roles. The Self role lets everyone edit their own records, profile information, private documents, etc. The Member role is important in Space: it defines the base level of permissions available to everyone in your organization.

The Member role defines your organization’s approach to working with Space. Will every member be able to create and manage new projects, or will you work with a top-down approach where an administrator has to set up projects for organization members? By default, the Member role is configured to allow for self-organized teams.

In Administration | Roles, a Space administrator can configure the default permissions for predefined roles. Have a look at the various permissions that can be toggled for every role, and customize Space to your liking.

Project roles have to be configured at the project level. However, administrators can configure the default roles and permissions for new projects under Project Templates.

Project-Specific Permissions

By default, Space enables self-organization. This means that every member of your organization can create a new project and manage roles for that specific project.

When creating a project, you can choose whether the project should be internal or restricted. Internal projects, by default, are visible to every member of the organization. Restricted projects are only visible to members you explicitly add to the project.

Upon project creation, the aforementioned project templates are applied and predefined roles are added to your project. For internal projects, the Organization Member role grants every organization member permission to view issues and boards, read Git repositories, and more. For restricted projects, the Organization Member will have fewer permissions enabled to make the project invisible to non-project members.

For both project types, you can configure roles (and project-specific permissions that are granted) in the project Settings. If needed, you can also create a new role that grants a different subset of permissions.

Note that the Automation Service role specifies the permissions that are granted to the Space Automation service. By default, Space Automation has read access to your project’s Git repositories, can read and write to package repositories, and can use parameters and secrets. If needed, you can expand these permissions. For example, if you want to create and push a new commit from an automation script, you will need to grant the Write permission for Git Repositories.

Adding Users to Roles

With roles set up and permissions covered, let’s look at how to assign them to member profiles.

Global Permissions

The System Admin role and any custom roles you have created can be managed from Administration | Roles. Global permissions have a Members tab, where you can assign or revoke a role for an individual member:

Team Permissions

Assigning a Team Admin, Team Lead, or Manager role can be done in Administration | Teams, and then select the team you want to manage roles for. Administrators can be managed on the Administrators tab, the manager can be assigned on the Info tab.

Project Permissions

You can manage access to a project in the People tab found on your project sidebar. It lets you add or remove team members and assign predefined roles that are valid for this project:

• The Team tab lets you grant or revoke the Project Member role.
• The Collaborators lets you grant or revoke the Project Collaborator role.
• The Administrators tab lets you grant or revoke the Project Admin role.

For custom project roles, you can add or remove members in the project settings under Settings | Access.

Summary

In this blog post, we have seen how users can authenticate with Space. We covered how to manage roles and permissions, and that these can be global, team-specific, and project-specific. 

Basic permissions control how much self-organization you want to enable in your Space organization. By default, Space lets every organization member create and manage projects, and configure roles and permissions within a project.

Give JetBrains Space a try, and let us know your thoughts in the comments below.

Subscribe to Space Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!