Industry and Market Competitors

Many IT and Security teams do not have Active Directory (ex. using Google Workspace and/or Okta) and need powerful role-based access control (RBAC) policies and features for managing their users and their access.

We co-exist in the Identity Governance and Administration (IGA) industry as an open source tool and believe that all of our commercial market competitors are doing a great job at their target focus area. We want you to make an informed opinion about the right tool(s) for your organization since one size does not fit all.

Please read the problem statement if you haven’t already.

Industry History

Origins of Microsoft Active Directory

In the “old days” before we used a variety of SaaS vendors to conduct business, we used Microsoft Active Directory with all of the users and the devices that they use joined to the domain. This centralized model works well when you have physical offices and your applications, devices, and users are using technologies in the Microsoft ecosystem.

You simply signed into your computer with your username and password and your applications were on the same domain and internal network. We rarely or never needed to access work applications in a web browser, and the few that you did either used VPN or you had a username and password for that application that wasn’t the same as your Active Directory credentials.

Remember those 8 character passwords that you had to remember in 2005 that required at least 1 number that you kept on a sticky note in your desk drawer or stuck to your monitor? 🫣

Growth of SaaS

The industry has evolved into a decoupled collection of web-based software-as-service (SaaS) applications. Each vendor now operates autonomously and since they are not federated with Active Directory, they maintains a database table of users that can access their application. For the most part, one application does not know how another application is configured or which users they share.

Unlike the old days where you trusted that users were on the same network, you now have your business applications being accessed over the public Internet.

IT Administration Without Microsoft

Over the last two decades, a minority yet still large percentage of organizations no longer (or never did) use Microsoft for their directory services or authentication since all of their applications are web-based and no longer need users to be joined to the domain. Many tech companies are using Mac and Linux machines with Google Workspace (400,000+ customers) and SSO providers like Okta (18,000+ customers) or Ping Identity.

We built Access Control for the companies that don’t have Active Directory and need powerful features for managing their users and their access.

If your organization uses Microsoft technologies predominantly including Active Directory or Entra ID (formerly Azure Active Directory), then there are many tools and vendors in the industry to help you administer and enforce policies for applications, policies, and group membership. Access Control is intentionally not built to integrate with the Microsoft ecosystem.

The Need for Security

Without traditional firewalls being used for accessing applications, this has introduced the need for security concepts and frameworks related to Zero Trust Architecture (ZTA) which focuses on how to identify which users and which devices are allowed to access your applications since we can’t inherently trust any person or any device on the Internet.

Many organizations have already implemented Device Trust practices to ensure that only devices on the Internet that they know about and comply with their policies, presumably being possessed by employees or contractors, can authenticate with their applications. You will see this referred to as Mobile Device Management (MDM) for the asset management and configuration state of devices, and Endpoint [Threat] Detection and Response (EDR/ETDR) for the continuous monitoring of threats and traffic as the device is used day-to-day to mitigate the risks related to Endpoint Security.

Compliance Frameworks

In addition to day-to-day operations with SaaS applications and security configurations, most organizations have one or more compliance frameworks that they need to adhere to.

There are several overlaps with the controls, however the key emphasis for Identity Management tries to solve for user authentication and authorization, least privilege, access reviews, and ensuring consistent and auditable activity related to when and how users are granted or revoked access to applications and ensuring their access is appropriate at any given point in time.

This is a labor intensive process that usually has several people at your organization focused on performing the audits internally and in collaboration with external auditors.

Best Practices

It is important to keep in mind that compliance frameworks should be your lowest common demoninator to ensure your controls and process are up-to-spec.

There is an additional layer of cybersecurity best practices and automation that are not part of the compliance frameworks. There is no common standard, only industry trends, so it’s important that you rely on vendors that have a vested interest in securing your data and applications with leading edge technologies and best practices, usually by employing engineers that are on top of these trends and building and improving the software that you’re using for day-to-day operations.

It is a commonly misunderstood perception that the compliance frameworks tell you how to do something. Unfortunately, in many cases it’s only a rough guideline definition of “what to do” and now “how to do it”. For example, there is no a compliance control that requires 64-character passwords with symbols generated randomly and saved in a password manager; there is only a control that says that a password policy exists and the organization has determined an appropriate minimum length.

As we see the rise of 2FA factors being used, passkeys and device trust authentication, we will see an increase of N/A on audit reports that use compliances controls were written for the circumstances of the past.

We do not believe compliance controls are weak or bad, however the industry and cybersecurity threats are rapidly changing, and you should try to stay ahead of and beyond what the checkbox says you should have.

Authentication Vendors

As the industry has tried to get a handle on SaaS application authentication over the last two decades, we’ve seen the rise of web browser single sign-on (SSO) vendors that provide a consolidated interface for users to authenticate with their email address, password, and two-factor authenticators configured with the SSO vendor.

The value proposition for SSO includes a few of the following benefits:

enforcing authentication requirement policies at the gateway
no password to remember on the authenticated vendor website
single username and password or passkey that can be used across multiple applications
unified user experience

As SSO was developed, we saw different approaches for consumers and businesses that have been branded as social SSO and enterprise SSO respectively.

You can think of social providers as public consumer SSO and enterprise providers as private business SSO.

With social SSO, vendors simply want to make it easy for users to start using their services without creating an account or remembering yet another password, so they allow you to sign in with your Facebook, GitHub, Google or other services that many consumers have.

After you successfully authenticate, the vendor is provided with your your name, email address, and a unique ID that they save in their database to establish your user account on their end, and solve for the identity principle of verify that you are who you say you are, also referred to as authentication.

Keep in Mind: Social SSO was designed to let anyone with an account on that social service to create an account and authenticate. It does not control or manage whether or not specific users are allowed to authenticate, which is the tip of the iceberg for the industry challenges with authorization that Access Control is focused on.

Once a user has been authenticated, it is up to the vendor SaaS application to handle permissions or role assignment for each user. Many applications do not have complicated roles and simply have the concept of users and administrators. When you sign in for the first time, you are granted a user role by default that may provide varying degrees of data access and features, however from a security perspective for work applications that have job roles and least privilege concerns, it is usually too permissive for everyone in your organization.

Enterprise SSO

An Enterprise SSO vendor provides private business SSO that allows organizations to establish trust relationships to ensure that only users that IT/Security know about (aka “have provisioned”) can authenticate with applications that the organization trusts (aka “have been assigned”).

If you sign in to applications at work in your web browser with Microsoft Entra ID (formerly Azure Active Directory “AD”), Okta Workforce Identity, Ping Identity, etc. using your work email address, then your organization is using enterprise SSO.

If you sign in to your work applications with Auth0 (aka Okta Customer Identity) or Google using your work email address, then you are using social (consumer/customer) SSO but may have compliance and/or provisioning challenges that Access Control can help solve.

The enterprise SSO features add additional value including:

assigning or un-assigning users from the applications that they are allowed to access (least privilege)
audit and compliance control requirements
group rule management using profile attribute metadata
onboarding and offboarding automation with human resources information system (HRIS)
providing a single gateway that all users have to pass through that you can provision and block/deprovision users from passing through
unified admin experience

As you read more about Access Control, keep an eye out for how we improve group rule management using profile attribute metadata.

Authorization Vendors

Many of the challenges related to permissions, baseline/birthright entitlements, least privilege, role-based access control (RBAC), access requests, and just-in-time (JIT) access provisioning, deprovisioning/offboarding automation, and user access review audits are categorized as Identity Governance and Administration (IGA).

There are several software vendors that address this market including medium sized (ConductorOne, Lumos, Okta Identity Governance, etc.) and large sized ones (SailPoint and Saviynt).

However, many organizations don’t have an IGA vendor until they get larger because the features built into their SSO vendor are sufficient. For example, Okta makes it easy for you to assign your users to applications or to groups, and then you can assign groups to applications or configure SCIM provisioning for pushing users to eligible applications.

As you start to outgrow your SSO provider’s features, you have a few different options:

Easy Button: Build a collection of automation workflows based on your team’s needs using your existing no-code vendor (ex. Okta Workflows, Tines, Workato, Zapier, etc.). You may outgrow this faster than you think, and without a centralized database or configuration library, you may create more tech debt than you realize.
Homegrown Scripts: Build your own primitive scripts (or tools) that you can run on a schedule or on-demand as many time as needed to solve the job in a non-complicated, but perhaps non-scalable way.
We’re Biased: Continue reading the Access Control docs 📚, see if it’s a fit 🤩, and try it out 🚀. We built Access Control because we outgrew our scripts and couldn’t find a vendor that met all our needs.
Buy: Evaluate one or more IGA vendors. If you work in a heavily regulated industry, then this may be the only option since you need the audit, legal, and security protections that commercial vendors offer.
Hire: Hire more team members on your helpdesk or provisioning team to handle requests.
Change the Business: Improve your business processes or make different policy decisions to become more efficient (ex. restructuring group names and changing group rules).
Ceteris Paribus: It is still a safe answer to do nothing and continue what you’re doing. Your circumstances may change in the next 12-24 months, or you can just accept it as an inefficient fact of life with how your organization does business.
Forget RBAC: We don’t recommend this one 🫣, but you can simply have everyone in the organization or a specific department have access to everything, and trust they won’t abuse their permissions. It worked when you only had 100 employees, surely it will be the same? 🥴 Please get approval from your executive team and your auditors before making this decision, because this might cause a resume generating event (RGE) or early retirement from the industry. 🏖

As an open source project, we want to be as transparent as we can with your options and the tradeoffs of each.

Understanding Your Needs

If you have a need for Identity Governance software, then you are likely encountering growth or maturity challenges that are largely dependent on the processes in your organization and the applications in your tech stack. In other words, what works for one organization may not work for another.

Having been on the customer side (in your shoes), we’ve done several rounds of build vs buy discussions, proof of concepts and demos, and found pros and cons with each of them.

As part of this discovery journey, we learned a lot about how each of them were catering to simple or complex needs for companies of various sizes. All of them are good (none are bad) at what they focus on doing well, however you need to find the right fit for your organization since there is not a “one size fits all” vendor.

It is important to keep in mind that “enterprise grade” is a relative term in the IGA market, and it is more important to find the right technical solution rather than only looking at the leaders in the Gartner Magic Quadrant. The smaller and mid-sized vendors are enterprise grade for companies with SaaS tech stacks while the larger vendors are better for traditional on-premise application tech stacks. If your organization is less than 10 years old, you likely have a SaaS tech stack and should consider the smaller vendors. If you’re familiar with the analogy of not driving a semitruck to the grocery store, the same philosophy applies here.

The goal should be to automate and streamline the day-to-day access management processes for the users in your organization, not buy brand recognition based on what you think the auditors will want to see. If you buy the right technical solution, the auditor requirements will be met already.

As you grow above 500+ users, we encourage that any engineers that you hire on your IT/Security teams are good at scripting or building custom internal software tools to help scratch your own itches.

If your company has more than 2,000+ users, then you will likely have unique needs that no vendor can solve off the shelf. Many companies at this size should considering having a team focused on Identity Management that is adjacent or overlapping with the configuration of your other IT tech stack applications.

The reality as you get larger is that you may need to integrate multiple products or build your own solution. It is perfectly acceptable that building your own solution is a collection of no-code workflows, scripts, or Terraform configurations that makes your existing vendors work better for your needs. You may eventually outgrow them, however that may be in 3 months or 3 years depending on your organizational complexity.

We built Access Control because we outgrew our scripts at GitLab and developed a vision for what we wanted the future of access management to look like. We open sourced it based on our company and personal values because we don’t want other IT and Security teams (is that you?) to have to reinvent the wheel for problems that we’ve solved.

Large Vendors

SailPoint, Saviynt, or CyberArk may be a fit if your organization is larger and has the philosophy of “no one was fired for buying IBM or Oracle”. They have a lot of features and flexibility that work for larger IT teams (50+ people) with complex integration requirements, large or legacy architecture enterprise applications, program management team support, and expectations that Professional Services is available for custom development.

Keep in mind that they are also more complex and expensive to manage and are analogous to being in the cockpit of a Boeing 747 with all the knobs and switches. If you have a team of 3-10 people that are full time Identity/IGA system administrators just for your IGA software (to fly the plane), then these are vendors that you should consider.

If your IT or Security Engineering team is a 1-10 person show (that prefers the simplicity of a Cessna or Learjet cockpit) with responsibility for most of your IT systems, then these vendors are not likely a fit for your organization.

Larger vendors are not a “set it and forget it” configuration and require continuous administration.

Small and Mid-Sized Vendors

We are seeing several startups and mid-sized offerings appear in recent years that are focused on the IGA market. Like all younger products, their direction and vision are still in flux and usually focus on the features for their marketing pitch. The benefit to being a smaller company or younger product is that they tend to cater towards the smaller and mid-sized organizations that they can grow with together in a partnership mentality.

Okta Identity Governance (OIG)

When you look at Okta Identity Governance (OIG), their marketed niche is around just-in-time access request approvals, compliance audits, and user access reviews, and integrate with Okta Workforce Identity.

Their product is designed to be built in collaboration with your existing Okta application catalog and triggering provisioning with the Okta Workflows that your team creates. If your provisioning needs expand outside of what you have already configured in Okta, you may run into some limitations. It’s important to note that our biased impression is that it’s a feature add-on rather than it’s own standalone product.

We expect to see great things from OIG in the coming years, especially with the growth of Okta’s AI initiatives and the ongoing investments in signal intelligence, however keep in mind that the product is new to the market and is trying to integrate in within a larger monolithic ecosystem so it is not as nimble as some of the other smaller vendors.

ConductorOne

When you look at ConductorOne, their marketed niche is also around just-in-time access request approvals, compliance audits, and user access reviews with founder origins previously working at Okta.

The difference between ConductorOne and Okta Identity Governance is around the “do one thing well vs trying to do too many things and missing the finer quality of life details”. ConductorOne has done a great job with building a foundation and user experience that appeals to power user IT and Security administrators for managing the back office IGA and compliance work.

They have invested heavily in extensibility and integrations with your own code using their API, CLI, and have extensive documentation.

If your pain points are coming from your compliance team and your IT and Security administrators like to build scripts with APIs, then ConductorOne may be a good fit.

If your IT and Security team does not have as strong of an engineering skillset, then you may want to consider Lumos. In other words, ConductorOne is for power users in the back office and Lumos is the easy button in the back office.

Lumos

When you look at Lumos, their marketing niche is around providing a seamless end user experience for the users that your team serves.

If you’re familiar with the app tiles in Okta, you will feel right at home with an app store for users to request access and streamline the approval workflow, while providing valuable business and license procurement insights into how much users are using each of your applications.

If you are looking for a turnkey solution for access requests for your Okta applications and a handful of other integrations that feels as painless as possible for your users, then Lumos may be a good fit.

In many ways, Lumos is the easy button to make IT become loved for make it easy on your users to request access.

Other Vendors

There are many other Identity Governance and Administration (IGA) vendors that we haven’t mentioned here but are worth a look to see if they are a fit for you.

Open Source Vendors

Evolveum Midpoint

Evolveum Midpoint open source IGA platform provides an open source alternative to the commercial vendors and provides a similar feature set to what you see in the market.

If you’re a fan of open source software, like the features as-is that the other IGA vendors offer, and it’s just a matter of cost, then Evolveum Midpoint may be a good fit.

Access Control

At the highest level, Access Control is an access management policy engine that uses user metadata (department, team, job title, manager, region, etc.) with multi-dimensional rules to attach users to groups based on their granular job role and handle pre-approved provisioning for group members and resources on various tech stack systems (see the docs) using best practices for role-based access control.

Access Control is not trying to directly compete with the other IGA vendors. We are trying to think different about why the problems that IGA vendors solve exist in the first place, and solve for the ones that are preventable with an emphasis on access requests and role-based access control using comprehensive user directory attribute metadata.

We are competing with the easy button configurations and scripts that you’ve built to integrate with various systems, solving for your high volume of access requests, and helping you take the next step towards maturity with improved role-based access control policy management and provisioning automation to streamline your onboarding (joiner), role changes (mover), and offboarding (leaver) processes.

At GitLab, we use Lumos as our IGA vendor as a turnkey solution to solve for our access requests (that should decrease over time) and use Access Control to manage our policies (to improve our automated provisioning over time). As you understand your needs, you may find that Access Control can supplement your existing tools and vendors.

Access Management automation and policy management is a journey, and our own dogfooding journey is still ongoing. We’re all in this together, and this our open source contribution to making the lives of IT and Security teams better so you can focus your energy on projects and tasks other than access requests.

Overarching Question: If our birthright/baseline/role policies are configured properly, why do we need access requests? Why not just push updates to the policy that is then used to provision access on downstream systems that use that policy?

Access requests are a bandaid that becomes permanent for many organizations, and the exception becomes the rule instead of just fixing the pre-approved onboarding checklist or policy. Access requests should be the exception if your policies aren’t configured properly.

Policy management is hard and provisioning access to resources inside of tech stack applications is even harder. We are trying to make it easier.

We want Access Control to help move your organization from a high volume of access requests towards powerful policy management to reduce the need for access requests and create a near-invisible access provisioning process with the lowest burden on users and approvers as possible. Your manual checklists will hopefully shrink or go away too.

We’ve designed Access Control so that you can easily deploy Access Control alongside your existing tools with nothing more than a few API keys (they can even be read-only to start with), and let you gain visibility into your organization. You can adopt features when you’re ready to optimize your existing pain points. In other words, you don’t need to manage all 1,500 of your Google or Okta groups right away, you can start with automating the first 5-10 that are the most annoying to manage.

Since Access Control is open source, you or the engineers on your team can self deploy and adopt it with a low amount of friction since it’s just an internal tool that is fancier than the scripts you’re likely already using.

Please see our Problem Statement and How We Fit to see if Access Control is a fit for your organization. You can explore the rest of the documentation to learn more about the configurations and features for the pain points and problems that your team is facing.