Q&A: Babak Sadighi, David Brossard on 20 years of access control and authorization

Kelly O'Dwyer-Manuel   ·   Tuesday, October 3rd, 2023

I recently sat down with Babak Sadighi, founder and Head of Strategy, and David Brossard, Chief Technology Officer, to discuss some of the highlights and takeaways in reflecting on twenty years of access control and authorization within the cybersecurity market.

Granted, this wasn’t 20 years ago, but what were access control and authorization like when you first started in the market?

Babak: At that time, organizations were very focused on role-based access control (RBAC) as their priority was managing profiles and identities.

Really, it was about provisioning or deprovisioning – those were the big trends.

Authorization and certainly dynamic authorization weren’t top-of-mind at all. It was all about identity governance and administration (IGA) with most enterprises in the early dates of IGA implementations.

A few of us did see the challenges with an RBAC model because it didn’t support real-time decisions, but overall, access was very much focused on IGA and role management.

David: If you go back to, say, 2005, it was really the early days of web services and distributed systems.

Externalized authorization was also nascent and the only way to achieve that would be to plug in something like a backend Lightweight Directory Access Protocol (LDAP) so you could use the same credentials in multiple apps – which is more about federation than authorization.

Despite the fact eXtensible Access Control Markup Language (XACML) existed, born in 2001 and better refined in 2013, authorization was largely an afterthought and existed within each application.

Even through 2012, you could certainly argue authorization remained an afterthought. It was when the National Institute of Standards and Technology (NIST) published their paper on attribute-based access control (ABAC) in 2014 that was a watershed moment for authorization.

And then if you look to 2023, we see another fundamental moment because we see Identiverse and Gartner note that authorization will be a major trend.

At the same time, we’re also seeing a slew of new start-ups focused on authorization.

All of this points to this year being another major marker for the evolution of authorization.

What is the biggest change you’ve seen from then until now?

Babak: One of the biggest changes has been the maturation of authentication, single-sign on (SSO) and federation.

Big players like Ping, Okta and ForgeRock have brought huge growth to that market because of the changes they’ve made to how people log in.

If you think about it – even ten years ago, authentication was quite different. Access meant logging on, more often than not at a corporate office or using a VPN or a physical device that generated a code. It seems archaic compared to where that market is now.

This growth, in particular, has really set the stage to be ready for dynamic authorization.

That maturity means many of the Global 2000 enterprises understand why they need fine-grained access control.

We no longer need to spend significant time introducing that concept or advocating for authorization – the need is there and it is understood. Twenty years ago, this evolution was hard to see.

In thinking about authorization specifically, the fastest maturity has certainly come in the last five years, as enterprises realized the need to better enable both employees and customers to access assets and data in a variety of ways.

As enterprises prioritize Zero Trust, the need for scalable dynamic authorization will continue to grow.

David: I think one of the biggest changes I’ve seen is the relationship between authorization and developers.

Historically, we’ve seen a lot of focus on how the IAM team considers authorization, and then how the business or application team should be involved. Once you see the emergence and maturity of OAuth, we started to see more conversations about how developers should consider authorization.

Another significant change has been the maturation of authentication which has led to the emergence and broader adoption of multi-factor authentication (MFA), but also a more streamlined UX, which was something that used to be done very piecemeal.

Now, more or less, we have the same authentication experience even from company-to-company.

I think this is a good development for security in general, because if you have a good user experience, it’s easier and more likely for employees to make good, secure choices and there’s less of a chance for mistakes to be made.

And as Babak notes, the emergence of Zero Trust has been a big change.

In terms of access control, Zero Trust really meant the end of the reliance on the VPN as a primary authentication tool.

Because the pandemic changed the scale at which VPN was used (before that, there would be a small percentage of an enterprise’s employee base that traveled or worked outside of an office), it changed the barrier model.

There was confusion as to where to put a barrier. Zero Trust put an end to that conversation because you no longer require a barrier – you need to verify everywhere. That’s a massive change.

Specific to authorization, a big change has been around languages. We’ve seen the emergence of the Abbreviated Language for Authorization (ALFA), Open Policy Agent (OPA), and newer languages like Cedar and IDQL.

All of these are important steps in the maturation of authorization and point in the direction of policy-driven authorization. It’ll be interesting to see how these continue to evolve.

Let’s talk surprises. What is a trend or technology that may have emerged (even as just an idea) and you thought would be a game changer, but didn’t catch on?

Babak: I think looking back we thought the need for dynamic authorization would pick up faster and happen earlier.

We did not understand how slowly this would emerge on the back of the gradual overall maturity of identity and access management (IAM). Any new concept in the IT world takes a long time.

A surprise that was initially good was the emergence of Zero Trust.

I know the market has talked about Zero Trust for some time, but it made the shift from an ideology or aspirational goal for enterprises to a pragmatic strategy in the last five years. It still could be a game changer and does highlight the need for a dynamic authorization solution.

The biggest stumbling block for Zero Trust is perhaps its overuse as a marketing term.

There are a lot of examples of vendors promoting a “Zero Trust solution”, which is misleading.

Zero Trust is not a solution, rather, it is a strategy that will encompass a variety of solutions working in concert.

In fact, this problem has become so pronounced that while at a recent industry conference, I heard a speaker start his session by apologizing for using the term ‘Zero Trust”.

For the promise of Zero Trust to be realized, vendors must do a better job of offering pragmatic and meaningful ways their solutions can contribute to a successful Zero Trust implementation.

Babak: This is a good question. I think there have been lots of surprises. The thing that has surprised me the most has been the relatively slow adoption of XACML and of ABAC overall.

If you look at OAuth, it’s super complicated – you have to do threat modeling in OAuth and authentication to understand whether your flows are secure.

Authorization is more straightforward, yet still people struggle to understand it. That may be why you see new languages emerge to try and solve this problem.

All of these new efforts really try and ‘reinvent the wheel’, if you will.

What is the biggest thing that has not changed in the last 20 years? Why is that the case?

Babak: I think the overall pace of change has been surprising.

Our industry tends to be measured in its evaluation and adoption of new solutions and technologies, which is why we still see a lot of the same approaches – RBAC, for example – persisting all these years later.

In some cases, the issue remains the same but how we refer to it has changed. We do not talk as much about things like “Shadow IT”, but we know that issue still exists, just in a different way.

David: For me, what hasn’t changed is the poor uptake on policy-driven authorization by the software development community.

There’s lots of blame to go around for this. Some of it is because there’s been a lack of PEP development, so you can blame vendors as well.

Additionally, the standards community has, on the whole, been a bit slow-moving, so we haven’t seen any significant changes to the language since 2017. You still see a lot of queries in Stack Overflow looking for answers, so that’s a gap that has challenged broader uptake.

What are the two or three biggest takeaways enterprises should take away from the evolution of access control and authorization?

Babak: For me, it would be these:

Authorization is not only about security; it is also about enabling the business. If you do it right, authorization is a way in which your enterprise can offer new services to employees and customers much more efficiently.

So often we think about authorization as a way to prevent or block access, but it can unlock so many possibilities if done correctly.

Authorization can’t be done in isolation. Authorization as a concept isn’t new, but the traditional way of isolating authorization within each application simply isn’t sustainable.

Authorization impacts many aspects of an enterprise and has a lot of dependencies to other technologies including identity management, authentication, and application development.

David: For me, they’d be:

Authorization is important. Now that you’ve freed up your cycles with regard to authentication and basic IAM, it’s time to focus on authorization.

Authorization does not reside with a single team. Because responsibility for authorization lies with a combination of the IAM team and the application team, it’s challenging – you need an overlap where there traditionally isn’t one.

And if there’s no overlap, it falls into a crack.

That’s not to mention that data teams and API teams need to be involved in the conversation to build a strong framework.

Authorization shouldn’t be something you have to do, but should be something you want to do.

As an example – development teams might be able to save 20% of their time, by implementing an externalized authorization solution.

If your enterprise wants to be more agile in how you develop apps and more ‘future-proof,’ then externalized authorization is the answer.

Language doesn’t matter if you have ways to go back and forth between formats.