The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Category | Authorization and Authentication |
|---|---|
| Stage | Manage |
| Group | Authentication & Authorization |
| Maturity | Complete |
| Content Last Reviewed | 2022-05-18 |
Thanks for visiting the direction page for Authentication and Authorization in GitLab. When verbally speaking about the team, we mostly call ourselves "Auth", becuse, well, the alternative is a mouthful, but it does describe our team well. You're welcome to use whichever you'd like, we respond to both!
The best way to help is to take a look at our roadmap. Feel free to comment on individual issues if they are of interest, and tag @hsutor, Product Manager, so she sees your message.
Authentication and authorization are critical, foundational elements to keeping resources secure but accessible. This is of particular importance for large enterprises or companies operating in regulated environments; for an authentication strategy to function, it must be secure and scalable. Onboarding/offboarding new employees should be automatable and not allow unauthorized users to access sensitive information.
Furthermore, security strategies have evolved from one of assumed trust within a trusted network. Historically, most organizations assume that authenticated users coming from a trusted source are allowed to access resources - those outside, if not on a VPN, cannot. However, security perimeters have become increasingly porous and an assumed trust model begins to break down with more services shifting to cloud and more employees BYODing or working remotely.
While GitLab's supported strategies meet most expectations (especially outside of the enterprise), our strategy is to aggressively invest in further improvements to authentication and authorization, with a particular focus on the needs of the Enterprise customer segment.
Our objective, as a team, is to enable GitLab administrators to strike their desired balance between security and accessibility for their users.
The primary audience for future effort are administrators in medium to large enterprises. These are privileged, sophisticated users in companies managing employee identities with a single source of truth; this may be a series of LDAP servers or an IdAAS service like Okta. Automation matters - we should minimize the amount of manual work needed to onboard/offboard an employee and be able to assign permissions automatically - but the must-have is security, especially in sensitive environments operating under regulatory scrutiny. We need to strike a balance between being overly permissive (e.g. unintentionally allowing access to an offboarded employee) and overly restrictive (e.g. getting in the way of a developer's workflow and annoying them with reauthentication requests). Security is top of mind for GitLab administrators, and our roadmap reflects the importance of administrator control over users across every entry point in the application (SSH, Username/Password, Tokens).
We're currently focused on broader and deeper support for identity management and authentication strategies. Our objective is to allow users to quickly join GitLab with the right level of access, and building support for large organizations to quickly onboard and offboard users is essential.
For large organizations, we also need to make sure that users are armed with the right level of access. GitLab's role-based access control has served small teams well - and fits with a permissions model where anyone can contribute - but makes it challenging for large, security-minded organizations to build the level of granular controls and variation they need.
We are also acutely aware of the increasing security needs in Authentication and Authorization. The credentials that users are able to obtain are the "keys to the kingdom" and in a large enterprise, there needs to be strict inventory and management of these credentials, ensuring that their use and scope can be monitored and revoked if necessary.
The Authentication and Authorization team is currently at about half of its full capacity. When we do have capacity, here is a peek at what we are working on.
Items at the top of our list:
Authentication and Authorization uses a board to highlight issues we're going to be working on. Hover over each YY:Quarter label to view approximate timeframes. If you're not confident an important Authentication and Authorization issue is on our roadmap, please feel free to highlight by commenting in the relevant issue and @ mentioning hsutor, Authentication and Authorization Product Manager.
Atlassian Cloud - Access has many of the same Authentication and Authorization features as GitLab. It appears that we are hearing similar needs from our customers - they are currently building a feature that allows customers to claim existing users to have tighter control over them, which we also have on our roadmap.
They also plan to roll out more granular user permissions, starting with the ability to define a set of access policies around Statuspage.
GitHub just introduced an optional expiration for Personal Access tokens, a feature that we have had for some time. In GitLab Ultimate, administrators can limit the lifetime of personal access tokens.
In GitHub AE, Okta SAML just shipped, and SCIM support is on the near term roadmap. GitLab already supports any SAML provider (including Okta). We also already have support for SCIM on our SaaS product. Extending SCIM to self-managed GitLab is on our roadmap for this year.
GitHub has lots of plans for their Enterprise Users, including allowing them to revoke their enterprise membership, allowing enterprise administrators to assume control of unowned groups, and offering an easy way for users to contact their enterprise administrator.
GitHub is also rolling out its customized roles and permissions (currently in Beta) to Enterprise and AE. Customizable roles and permissions in GitLab is at the top of our list and is currently in the design validation stage, with development to begin soon.
This category is currently Complete. The next step in our maturity plan is achieving a Lovable state.
Complete state does not mean a category is "finished" and is no longer a priority. Even categories that are considered Lovable require continued investment.Complete Group SAML Sync for self-managed GitLab instances. This will be completed in GitLab 15.1.
Complete Flexible Roles and Permissions MVC. To get to the point of completing this MVC, we will do technical discovery that will help us understand constraints which may impact the design.
Domain Verification MVC will be the first step in our Enterprise Users Epic. Once a domain is verified, administrators can claim any users belonging to that domain, turning them into Enterprise Users.
Parity in administrator features between self-managed and GitLab.com. Workspace is creating the container that will allow us to move existing self-managed administrator features to GitLab.com.
Iterate on our MVCs for both Domain Verification and Flexible Roles and Permissions.
Allow Administrators and Group Owners more control over their claimed Enterprise Users
Our top vision item is to build a capability for Fine-Grained role definition.
Other items on the list: