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.
| Group | Authentication and Authorization |
|---|---|
| Stage | Govern |
| Group | Authentication and Authorization |
| Content Last Reviewed | 2023-09-19 |
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 provides authentication solutions that aren't tied to humans to faciliate automated processes that have less security risk. We will continue to invest in making these non-human authentication methods easier to manage.
Roadmap Items at the top of our list:
Every milestone, we devote capacity to customizable roles. This is our highest priorty work item.
We are prioritizing permissions that will have the most customer impact. Feel free to vocalize your permissions requests on this feedback issue.
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 permission development guidelines.
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 have most of the basics of the customizable roles UI complete, and will start rolling it out in the 16.3 timeframe. Today, customizable roles are managed only via the API.
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.
Enhance our token rotation support to allow our users to avoid any unexpected surprises when token lifetime limits are enforced in Summer 2024.
Continue to add customizable permissions to the framework, with contributions from other teams. Work on permissions that exist between Developer and Maintainer so that Maintainer is less likely to need to be assigned. This is a role that is extremely privileged, but with many permissions that aren't actually used - making it risky from a security and compliance perspective. Splitting off some of the permissions from the current Maintainer solve some of these issues.
Begin to tackle some of the token related issues that emerged as high reward, low effort from the Token Management Working Group.
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.