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-09-14 |
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!
If you'd like to learn a little bit more about our team, we recently made a video that talks about the realities of working on GitLab's Authentication and Authorization team.
If you'd like to have influence on what the group is working on, the best way to help is to comment on individual issues if they are of interest, and tag @hsutor, Product Manager, so she sees your message.
We are on a mission to empower GitLab system administrators with the toolkit they need to create their desired balance of security and accessibility for their GitLab experience.
Authentication and Authorization is the first impression any new customer has when they configure their shiny new GitLab instance, and we aim to make it as seamless as possible: from that moment of first logging in, to onboarding users, to managing the basic security rules for their instance.
We recognize that authentication and authorization are more than a shiny frontend. These are critical, foundational elements to keeping resources secure but accessible.
No matter the size of a company, for an authentication strategy to function, it must be secure, flexible, and scalable.
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, Azure AD, or GSuite.
Our audience cares deeply about security, and is well-versed in all of the areas of the platform where authentication loopholes exist. They are often under tremendous scrutiny to meet various compliance and audit standards from organizations outside their own.
They expect ease of use in terms of onboarding, offboarding, and maintaining control over their users, particularly in an Enterprise context.
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.
Roadmap Items at the top of our list:
Here's a video we made about the current state of customizable roles and permissions - the problems we are trying to solve, where we are in the process, and the UX designs:
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.BitBucket / Atlassian Cloud has their sights focused on more administrative settings, particularly at the project level. They are also allowing administrators to standardize settings across projects by having respositiories under the projects follow inheritance. This is very similar to the way GitLab works.
Later this year, Atlassian Access will allow customers to claim a subset of users from the verified domains in their organization. We plan to enable this same use case in GitLab within a few milestones, starting with our claim enterprise users MVC.
Longer term, BitBucket will add more controls around securing tokens - something that seems to be a common theme, as it's very important to security posture. It is interesting to note that BitBucket does not yet support provising via SCIM, although it is on their roadmap. Automated user provisioning is table stakes for Authentication capabilities in any software product.
The big news in the GitHub world is that they just realized their open source Identity and Access Management Solution, Entitlements. It is great to see Microsoft release this as open source! It looks like, for now, Entitlements is limited to LDAP only. Entitlements seems like it attempts to solve for a few long standing IAM pain points: lack of flexibility, auditability, and scalability.
They also have a neat new feature which allows you to link your GitHub and Twitter accounts to create a verified identity for developers, showing that digital trust is more important than ever.
On the roadmap front, GitHub is also providing improved control over Personal Access Tokens, as well as continuing to add more administrator controls, like the ability to remove members from your Enterprise (I'm a little surprised this wasn't included in the first pass, TBH!)
Enterprise Users seems to be a focus for GitHub. Their roadmap contains a few things related to Enterprise Users, like optionally redirecting Enterprise Users to SSO when not authenticated – here is the GitLab issue for the same. They will also be adding the ability for admins to block commits with noncompliant messages
GitHub allows Enterprise Cloud users to create custom roles for their users, however, it seems more limited than what we are planning for GitLab's implementation. You can only create 3 custom roles per organization, and the roles must inherit from other, pre-defined roles. GitLab's version will allow you to create roles from scratch - they do not need to inherit from existing - and we also don't plan on limiting the number (though the feedback we've gotten from users is that they wouldn't create more than 7ish, anyway).
Overall, the following themes are being addressed by each competitor's Authentication and Authorization (or equivalent) teams:
Continue progress on Customizable Roles and Permissions. We have worked through the majority of our MVC for testing technical performance with custom roles and are going to use the next milestone to evaluate the final outcome.
Our MVC for Domain Verification is completed as of %15.4, and unlocks a lot of features in the Enterprise Users Epic. We now allow any provisioned user that matches a verified domain to bypass e-mail verificaion for any e-mail address belonging to the domain, which is something that our customers have been requesting due to the onboarding friction it causes.
Next up for Enterprise Users will be the claims process for existing users who match a verified domain who were not provisioned. This will allow a group owner to claim users who match their domains.
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.
Service Accounts - will roll Group and Project Access tokens into a new concept called Service Accounts, which will be better attuned to the needs of integrations rather than human users.
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: