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-05-24 |
Thanks for visiting the direction page for Authentication and Authorization in GitLab.
When verbally speaking about the team, we mostly call ourselves "Auth", because, 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 Auth is 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 recognize that every user that works in GitLab needs to authenticate, so this experience must be secure and scalable for everyone. Our target persona is administrators who implement identity, but end users of identity our are customers, too.
Security is top of mind for our customers, and by default, is also the highest priority 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 security 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, rotated, and revoked if necessary. In fact, there is even a shift away from using human-tied credentials altogether. They are too easily comprimised and prone to human error. Our team will provide authentication solutions that aren't tied to humans to faciliate automated processes that have less security risk.
Roadmap Items at the top of our list:
We are prioritizing permissions that will have the most customer impact. Feel free to vocalize your permissions requests on this feedback issue.
We are beginning work on the front end - today, custom roles is only available via the API.
We welcome contributors! If there is a permission that you really want, we encourage you to take it into your own hands and contribute it to the framework via our instructions.
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 is working on higher level tokens that provide automation with scopes that are larger than those of an individual user. GitLab already has these covered with project and group access tokens, and will be further refining this with service accounts.
BitBucket is making their external user features GA. These features allow companies to enforce 2FA policies on their users. They are also adding automated provisioning support into BitBucket from Atlassian Admin tools.
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 and auditing. With their addition of project and group access tokens, I am expecting to see the security improvements become quick to follow since creating more highly privileged credentials leads to increased risk.
GitHub is taking their granular permissions and applying them to tokens for GraphQL, personal access tokens, and adding an organization layer to manage these tokens.
Overall, the following themes are being addressed by each competitor's Authentication and Authorization (or equivalent) teams:
We will also start on the UI, which will allow users to create custom roles via UI. Today, it is API only.
Enterprise Users We are putting the final touches on our automated user claims process, which means that any user that matches a verified domain and was not provisioned will automatically belong to the Enterprise. This is more secure than purely relying on SAML and SCIM provisioning, and also eliminates onboarding friction for new customers - if a domain is verified, those users will be automatically claimed.
Service Accounts In %16.1, we plan to have at least the API or UI MVC available for users to create service accounts. Service Accounts are a more secure alternative to using personal, project, and group access tokens. They are unable to access the UI, are more auditable, and are not tied to a specific human user.
Support Azure AD overage claim for users who are onboarding with over 150 SAML groups. Today, the max is 150 groups, and any groups beyond that number will not be mapped into GitLab.
Continue to add customizable permissions to the framework, with contributions from other teams.
Our top vision item is to build a capability for Fine-Grained role definition and extend this to other credentials that follow users, such as Personal Access Tokens.
In FY24, we want to execute on the following goals:
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.
Authentication and Authorization as a service. Our customers come to GitLab to build software. Most software needs authentication built in. Our customers have to go outside our platform and adopt an out-of-the-box authentication solution, or build their own. In the spirit of "software, faster", we want to provide our customers authentication platform level services right where they do their work - in GitLab.