Why Policy-Based Authorization is Critical for Identity First Security

Hi everybody. Thank you for staying. I know you are anxious to join the Wolf Ride later on, so I hope you will find this interesting enough to stay for the duration.

I am gal, I'm co-founder at Plain id. I'm the CTO of the company and I'm going to speak with you about why policy based access control policy based authorization is critical for identity first Security. Typically whenever I'm speaking I like first of all to explain the topic, so we will start by understanding what is identity first security and then how policy based fits into that and supports that. We also see a case study of policy based authorization for data access and we'll see how identity First Security fits into all of that.

There is a bit of architecture slide, you know, just high level to wrap it all up. So that's what is planned for the next 20 minutes. And we'll start by what is Identity First Security? So just by the name, it's very understandable. Identity first, security means identity is at the center of your security, right? Your security design, but what does it actually mean? Identity first, what makes your security identity first? So I have a quote here by some of the other analysts, sorry, that's a quote from them.

Stating that enabling the right individuals access to the right resources at the right times for the right reasons. That is identity first. It's on not only having identity there, but it's also the understanding of the context of the identity. Why the identity is there, what the identity is trying to access, why now the identity is trying to access. Please note the focus is right, enabling the right individuals to the right resource at the right time. And the focus is right and like always, how do we know it's right? We know it's right.

If we can answer this question, who can do what, when and when, right? It's after all we are in authorization. So we need to answer this question. How do we answer this question in order to know it is right? So let's start with the who. The who is our identity. Our identity can be an employee, our identity can be an external user, a consumer or a partner, or it can even be a service account, whatever. What do we know about the identity?

Well, quite a lot of things. We know about the identity. We know the identity besides the idea, we know the identity role. Maybe we know the identity location within the organization or which country the identity is operating from. We know a lot of things about the identity and that can assist in answering the question. The next thing is what the identity is trying to access. The identity is trying to access financial records. The identity is trying to access medical information or whatever, some kind of stop secret files. Those would be our resources or assets. What do we know about them?

Well, again, there is some information we know about our assets as well. Let's say the identity is trying to access accounts. We know the location of the account, we know the type of the account, we know a lot of things about the account.

And again, that can be part of the decision. And the last part is the when. The question of the when. The when is the context of access. The user is now trying to access 8:00 AM or 8:00 PM from office or from home, from Europe or from the US or even from Israel. Any place he can try to access whatever is trying. And the combination of all of those pieces of information that leads to a decision to an access decision. And that is policy.

That is what we call a policy combination of attributes, relationship between attributes that leads to a decision that is a policy, but it's not enough just to have a policy in order to have authorization, right? To have an authorization solution in place, you need to look at four, four aspects. What are they? So first of all, they are, okay, first of all, they are enforcement. The decision needs to be enforced decision, there needs to be some kind of engine that makes the decision management. Obviously all those policies need to be managed.

They need to be managed in a consistent way, in a way that speaks both to the business and to the IT to the developers as well. And governance. Let's not forget governance. A large portion of IM is around governance. Policies also are part of that. An authorization solution is all of those elements. Policy-based authorization is an authorization solution that supports authorization policies enabling you to build those decisions in a consistent, flexible way and handles both enforcement decision management and governance. Now let's look at the sample case study, how that comes into play.

And the case study I chose is when a user is trying to access data, same simple, right? But no, this is actually one of the more complicated use cases there is, and let's see why. So when we want, remember, what we want to do is to enforce identity first security based on policy based authorization, right? So we have an identity and there is the data. What do we know about the identity? Maybe the identity is an Analyst trying to access data. In that case, the Analyst would probably be using a BI tool, some sort of BI tool to access the data.

Or maybe the user is a business user, he's not accessing the data directly, he's going through a business application and the application knows who the identity is. The data would probably know, would probably wouldn't know who the identity is. So in those cases, just a user trying to access data, how can we define our security? We need to know the identity. Where do we know the identity? Do we know the identity at a browser level? Is that good enough? Do we know the identity at the data level or maybe at the application level? How can we establish trust if we don't know the identity?

The identity must be known at the level the trust is established. This is crucial to understand, okay? Because there are a whole lot of solutions out there and there are a whole lot of marketing phrases. But eventually it comes down to what you understand you want to achieve with your security solution. And you need to understand that if you really want to achieve identity first can call it any way you want. Zero trust is also out there. You need to enforce at the level the identity is known. That's the only way to establish trust.

So in our case, for the Analyst, obviously we can't enforce on the browser level, not going into that now, but you know why? We know the identity on the data level, so that's good for us. But for that business user, typically the data wouldn't know them because we're using service accounts. So the only the the lowest level, which the where the identity is known is the business app. So you see why this is a bit of a complicated use case. We started with an identity trying to access data simple, but we have one data source and two types of identities.

One a business Analyst, another one, a business user both trying to access the same data. I'm not even starting with let's replicate that data for other data sources. That's another complication of the same aspect. So what do we do? How do we solve this use case? In order to solve this use case, we need what we call identity first security. We translate into identity aware controls.

Again, a lot of language that speak always the same. We need to know the identity. We need to enforce access at the level where the identity is known for the business.

Analyst, that would be on the data level for, sorry, for the, yeah, for the Analyst it would be on the data level for our business user. That would be on the business application level. But we want consistent controls, we want consistent visibility. How to achieve that. And now we are going to jump into the architectural slide. How to solve such a problem with an authorization solution.

You know, that's what authorizations are built for. Authorizations are built to solve just that authorization solution. A good authorization solution such as plane. Id have the support, the notion of central management with distributed enforcement because enforcement needs to be done at the level where the identity is known. And management needs to be centralized because you want your consistency, single visibility, one plane of control. So if you would look for example at this side, you would see that you have one place where you manage your policies.

That would be your administration point for the policies that feeds the policies feed all the time from external information, information to support who can access what and when, right? We said we have all those pieces of information around our identity, around the assets and around the conditions that feeds into the policy in order to make the decision. And then the decision is enforced.

Well, wherever it needs to be forced, it can be enforced on the application level, it can be on the API level, on the service microservice level or on the data level. That's how technology works. I always like to say no magic in technology, you just need to understand where you need to fit the bits, right? And that's exactly that. You can't just put a solution out there which would solve everything you need to understand the problem. And the problem with authorization is enforcement is distributed, management should be centralized.

That's the only way you can achieve consistency, central visibility and real control over your overall security. Okay, and that leads me to plain id. We build plain ID with that notion in place. Our authorization platform, it's a full SaaS authorization solution. Supports from one hand the management of authorization policies in a consistent visual way, supporting all the flows needed to manage authorizations efficiently. Approval workflows, policy as code, audit and governance, delegated authorization management. That's what you need in order to manage your authorizations, right?

You need to be able to see the policies, you need to understand the policies. You need to embed the process in development life cycle. That's why policy code is there as well. All of those are to be supported in the authorization solution. But eventually all those well-defined policies should be enforced all across the technology stack. And that is done with what we call the plain id authorizers. Those are technology ready components that support your application stack, support your APIs, microservices and data authorizations do not have just one language to them.

Unfortunately that's not authentication. Authentication today have a well defined standard, not not as it was, I dunno, 10, 20 years back, but you are not asking any questions about authentication. If you need authentication open ID connect is there to the rescue or maybe Samuel if you're still there. But that's not the case With authorization. With authorization, you need to adapt to that technology where enforcement is done in a microservice environment that would typically be in the form of a cycle in an api.

In an API space that would typically in collaboration with your API gateway in an application, well need to support whatever developers like to have, right? So all of that should be there and that's why plane ID is offering the extensible solution, the authorization platform that handles both of those aspects.

Again, just to summarize, the notion of identity first enables you to from one side see your identities. The other side, your assets in between. It's the management of the policy in a consistent consolidated way. And just one last slide. My takeaways from this session. First of all, I hope by this time you understand why policy-based authorization is so important for identity first Security. I really don't see any other way to support it. And second true authorization solution would provide and support the notion of central management with distributed enforcement capability.

That is a key, a capability or key notion for real authorization solution based on policy based. Thank you. Thank you very much gal for your interesting lesson.

Okay, we have three questions on this for you. Okay, and we have five more minutes, so that's a good timing. The first question that came in was identity first equals zero trust, doesn't it? Yes. What's Your opinion? So my opinion is yes. My opinion is there are multiple notions today in the market that speaks about zero trust, identity, first identity.

Well, eventually they all speak about the same thing. They speak about the notion of enforcing access across the path to the data, whatever the user is trying to access based on the identity assuring the access over and over and over again. We can call it zero trust, we can call it identity, well identity first. It's all coming down to the same thing. Yep. Okay. And then there's a second question. What is the difference between policy based access, attribute based access, conditional access, relational based access, or are we just doing a word salad?

Yeah, I think that's what we are doing. We are, okay. Well I think first of all, this is an evolution in the market, right? It started off, if someone remembers with acs, very, very old notion still, still still out there. Then wall based access control, which spoke about the notion of roles. Everyone thought that would solve all our problems today we know not so much. Still role is something which you are assigning to a user because we do not know everything about the user.

Then came in attribute based access control, which is basically, let's take everything we know from the identity and from the asset and make a decision. What's the problem, what's the challenge with attribute based? It came as a very technical notion, very specific implementation policies. We have come to solve both of those areas. Policies speak also about this business aspect of authorizations, how you manage those decisions, how you control how you govern. They incorporate both attributes and roles together in order to provide the decisions.

All those other, I know there is relationship based access, conditional based access, a lot of staff, they all speak more or less of the same. So okay, defining the access based on what we know, making the access dynamic and as much as as much as possible. Relying on the context of the access. And then the last question, if I have a policy and I have another policy, they could potentially in theory undo each other. Are you managing that as well?

Yes, We are managing above policies. Yes, absolutely. And I think maybe old notions of managing policies would allow that thing to happen. I think today this area has evolved and if you are interested to know how we are happy to show you in our booth.

Number 30, don't forget, please, you are invited to come. Okay, Thank you. Thank you.