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 and Authorization |
| Maturity | Complete |
| Content Last Reviewed | 2023-01-16 |
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.
With security being top of mind for our customers, it becomes top of mind for the Authentication and Authorization team. Our aim is to provide GitLab administrators the toolkit they need to make their GitLab experience both secure and accessible for their users - and to give them the flexibility to implement that in any way they choose. Just being able to securty authenticate with GitLab is not enough. GitLab administrators need to secure all authentication avenues into the product, manage their users using automated processes, and have fine-grained control over what their users can and can't do in the product.
To be more specific, we are keenly aware of the increased 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. In fact, there is even a shift away from using human-tied credentials alltogether. They are too easily comprimised and prone to human error. Our team will provide auth solutions that aren't tied to humans to faciliate automated processes that have less security risk.
Roadmap Items at the top of our list:
Given that OpenID Connect adoption keeps increasing, we plan to add support for groups within the next couple milestones.
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:
We will continue to iterate towards fully customizable roles, starting with permission consolidation, likely in the vulnerability reporting space. Again, more granular control over the vulnerability report is a common customer ask.
Next up for Enterprise Users will be an automated user claims process, which means that any user that matches a verified domain and was not provisioned will automatically belong to the Enterprise.
We are working on adding a visual indicator to Enterprise-managed accounts, so that it's clear to both users and group owners when their account is owned by their company.
Our top vision item is to build a capability for Fine-Grained role definition.
Other items on the list:
Passwordless Authentication - All of the major players in tech have aligned on using FIDO's passkey standard. This opens up the opportunity for us to implement passwordless authentication across our product. We already support webauthn, which gets us part of the way to going fully passwordless. Webauthn allows for the use of credentials such as biometrics and hardware keys as a second factor.
Better controls for access tokens. Our users need more visibility into their tokens, their usage, and to be alerted of their upcoming expiration. Administrators/group owners also want further insight into access tokens within the instance/group they manage.
Transparent credential policies and use monitoring - When a user's credentials are as powerful as they are within GitLab, it is only logical that GitLab administrators would want transparent insight and control into them. They should be able to define policies around how long lived credentials can be, and should be able to limit their scope. They should also be notified when a credential that supports automation is about to expire as to not disrupt workflows.