While authentication and authorization might sound similar, they are two distinct security processes in the identity and access management (IAM) space. Authentication is the security practice of confirming that someone is who they claim to be, while authorization is the process of establishing the rights and privileges of a user. Here, we talk to Tehila Shneider about authorization, authentication, and why authorizations remains a problem that is mostly unsolved.
Security: What is your background and current role?
Shneider: My current role is VP of R&D at build.security where I lead the development team. I hold a Masters in Computer Science, and my experience is in leading R&D groups across multiple domains, including the fields of mobility, artificial intelligence and in the defense industry of Israel.
Security: Why are authorization, access controls and permissions a big challenge for developers?
Shneider: Authorization is incredibly complex. You are managing users, groups, policies and resources whose hierarchies and relationships are constantly changing across your applications and infrastructure. Permissions for different resources might get updated frequently, and that needs to be reflected in your authorization across very large environments.
And at the backbone of access management is policy, which is driving the decision engine for your application. Authoring, managing and testing policies can be grueling and trying to manage this across all of your systems isn’t an easy task.
So when you decide to build an authorization system in-house, which most organizations do today, you need to build something that is high performance, low latency and can provide flexibility and scalability as you grow. You also need to build it in a secure way that can ensure proper access to your organization’s most valuable resources and can pass security audits.
You end up devoting a significant amount of engineering resources to build it and managing it can be very laborious.
Security: Why does authorization, unlike authentication, remain a problem that is mostly unsolved, in your opinion?
Shneider: You think about access management as having two pillars - authorization and authentication. Authentication, by its very nature, is somewhat simplistic. It’s binary and it happens once in a session. Authentication gives us the ability to recognize a user’s identity given a certain set of credentials so really, the only choice becomes what service will I use (Okta/Auth0/etc) in order to manage it.
Its complexity makes it difficult to build ‘the solution’ for managing authorization and policy management. Trying to author a policy that gives a user access to a specific row or column in a database, or granting API access according to HTTP method, headers, JWT tokens, claims, geolocation or other environmental context is not easy -- even for the most seasoned developers. There are numerous sources of data involved in the process of making an authorization decision. Trying to manage policy across all of your systems with those data sources will continue to pose a challenge to most engineering teams.
Security: How does this issue impact enterprise security?
Shneider: Authorization is ultimately responsible for who has access to your applications, services or resources. If any of these are touching PII, financial or other sensitive data, your entire enterprise security is potentially at risk. Broken access controls are listed in OWASP’s Top 10 Web Application Security Risks. Developers are playing a key role as gatekeepers of the sensitive data found in enterprise applications. As responsibility for secure code shifts left, developers are tasked with overseeing key security measures in application development, chief among them authorization and authentication. The time consuming, confusing and error-prone nature of these processes heightens the risk of insufficient software protection, leaving enterprises vulnerable to exploitation.
Security: What are steps enterprise security leaders can keep in mind in regards to their authorization policies?
Shneider:
- With a zero-trust security model, you always want to enforce policies in a way that doesn’t make assumptions about when/where the policy is being enforced. For instance, you don’t want to assume that a specific API call happens only after it has successfully passed a subsequent policy. You want to enforce policy each and every time.
- Unlike authentication, authorization policy checks can happen thousands of times during the course of a session. Because these calls happen so frequently, you need to ensure your authorization service coexists seamlessly with your application, preferably on the same host. It’s obviously not feasible to go back to a distant service for every API call. This means your policy decision point needs to sit as close to the application as possible in order to reduce latency and maintain high performance.
- Consider the different types of data sources you may need in order to make policy decisions. If access is allowed or denied based on the status of a Jira ticket, an account status in Salesforce or the employee type in Workday, the data from these applications needs to be brought closer to the authorization service. If each API call means going to the database in Salesforce to retrieve that information, latency and performance is going to be a problem. Bringing this data closer to the authorization service via caching allows you to fetch that information in real time in order to make a decision.
- Adopt both policy as code as well as security as code if you haven’t already. This will allow you to author, review, test, enforce your policies before they are put into production.
- We strongly encourage engineering teams to decouple their policy from the code. We speak to a lot of teams that end up baking their policy and decision making into their applications, but by doing so, it becomes incredibly difficult to manage your policies across all of your applications and infrastructure.
