Mans Hakansson - Beyond OAuth: Securing APIs with Policies & Attribute-Based Access Control

My name is Monson. I am with, besides the introduction today, talk about two areas, namely mainly how you can deploy dynamic authorization to APIs, why you should do that and how you can do that. And obviously also for microservices. And I think that timing wise in the marketplace, it is a very interesting time to talk about security. I mean, most companies are very busy building new services and business models, and they would like to introduce those to the clients, to the suppliers, to the vendors. And obviously they are using microservices and APIs to be the main vehicle and driver for that. So therefore I'm sort of thankful to give the authorization perspectives to two, those two to topics. Even that microservices and APIs are really business driven. There is always a technical implementation to this. And sometimes I feel that that talking about security and authorization with, with, with, with the, the implementing implementers of, of APIs and microservices, it is somewhat a technical discussion it's even development discussions going on.
And I would like to explain just very, very briefly, first of what, what access control in this case is. So it's a very, very simple process of after authentication to determine if a user has access to a service or not being a doctor, being able to review a medical record or something first, I'd like to say that that this is a particular business practice. Okay. I do understand that there are lower level of security that we need to deal with. And especially looking to Alexei say's presentation, you know, I'm only one little piece of that puzzle called attribute based or role-based access control, but, but being able to, to articulate a policy, meaning that doctors can view medical records of patients that they treat that is a business level authorization policy. And I understand that below this, we have a loads of other technologies that also deals with authorization in, in, in an it environment.
There is privileged access to databases. There are service to service calls. There are loads of other technologies that are in place, but if you help me now to stay on this business level where we can think of nurses, soldiers, bank, customers, and insurance agents, and talk about what they can do. I think this presentation would make sense to everybody. So there is a clear problem in this market. First problem that I see is that authorization is more or less always coupled to an application or data. And obviously we can think of developers and if they feel that they are doing something wrong and I don't think they are doing something wrong, they have been asked for a long time to develop business functionality, but what they have to do in order to actually give that to the users to the, to the business is to implement security controls inside they code meaning that is it's pretty, pretty, this is pretty damn hard to audit, you know, have no controls and visibility into this, especially since since authorization code might even be up to 20% of an application.
This is quite a big, big thing, not to mention the fact that we have also huge set of permission databases. I mean, tens of thousand millions of sort of access control list, profiles, roles, and groups that we have to manage and maintain and assign to end users in order to get the authorization to work. And clearly this does not scale. Okay. So we cannot apply the same technology that we have been using for some while now and apply that to the new customer APIs, the supplier APIs, the microservices architectures that we are doing. And obviously again, is this a technical discussion? Yeah, it is. But what we are applying, what we are trying to, to sort of advocate is obviously that we do some separation of concern and drag everything out of the application and the APIs consume authorization as a service and obviously something that would help a developer of a Porwal to actually view which, which documents should be available to the insurance agents.
What operations can that insurance agent do on this particular document? These are the things that we can do by utilizing a policy based approach to access control, meaning that we can have attributes and data describing the identity, but also the resource. And also the context of this whole thing, meaning the relationship between a doctor and a patient, for instance, the relationship between a soldier and a mission to understand if that soldier actually can get access to the data. This was sort of the introduction to, to, to my speech today. So it's, it's the summary. It is a business practice. You should have it as a central capability inside your IAM strategies and you should consume it as a service. It's a, it's a pretty simple message that we are sending now over to the sort of main topics. So how can we apply this to, to APIs?
And, and obviously we have a little model for this, so there will be no test on this, but, but I need to explain it briefly. So at the top we have end users trying to get to a record in a da in a database or an application. We have a notion of something called a policy enforcement top point in, in front of the application that stops. This request, sends this request to a policy decision point in the mill, which consumes a policy. We are evaluating the policy, finding out that we need to know more information before for, for giving a permit or deny. So we reach out to some databases, application services, or even directories to find that information and then make a decision, send it back to the enforcement point and voila, the enforcement either permits or denies this, this, this request. It's a pretty simple model.
So how you would apply this to an API gateway? Well, obviously the API gateway in itself becomes the policy enforcement point day by gateway is capable of a lot of different things. So one of the things is access control also pointed out earlier. It does authentication and that should happen prior to this, but when it comes to an authorization, the API is also good at communicating with other services using APIs. So what it can do, we send simple request to the decision point and we would automatically evaluate, sorry, the, obviously I forgot to talk about which API gateways you could have. So more or less we support all types of, of API gateway vendors. We have, for instance, this list, APG mules of Amazon x-ray CA technologies and others implemented already. This is a pretty sort of normal use case. So we have several customers actually deploying this.
So the API gateway can be of many vendors. We are also now looking into how Oracle and red hat fits into this pro into this process. But once, once the API gateway makes the request, we can go check the L ups on the databases for a contract, for instance, or roll or something like that. There is also the possibility to not go to the traditional databases and, and L ups. We can actually call to a service in the backend. This would enable, like we had a meeting this, this Monday in, in Berlin, actually one of our customer deploying a API gateway in an Amazon infrastructure and having sort of the, the, the, the, the whole access control mechanism being, being depending on a user management service and a contract service. And those were serving as PIP in the back back and to determine if the end user actually could get access to, to the document itself, the flow between the, the, the client and the service is two ways.
Okay. So it's one way on the inbound, but there is also an outbound flow and what we can do, we can, we can look, take a look in the payload that comes out from the service. So when the service returns the payload, we can investigate that and we can look into the data, data sets and find, and if we find PII data in there, we could easily also apply a policy that would tell the API gateway to redact this information. So this is, this is the, the normal setups that we have with customer Todays. But, but, but if you are working with API security, you might wanna say, but, Hey, Hey, I already do. Oof. And I do open ID connect. These are the primary tools that we use to make decisions on, on the APIs. And I would say, sure, this is definitely true.
And I support all this, the, the, the oof technology, the open ID technology, me being sort of a more Federation concept to share identity data between between APIs it's it's. It is an excellent way of dealing with authorization, especially when it comes to sort of the anti password pattern. So you don't have to, to give your password, but you can delegate access to an application in order to, to actually consume data on behalf of you. So this flow is also a very natural way of doing this, but what customers are telling us that oof, in some way is just like a scope, just like a role, meaning that we are implementing role based access control, again, even though in a modern modern scenario. So what we are trying to say, tell our, tell our customers that you should actually try and use both these technologies so that the aback technology can complement the ol and the open ID, making sure that we not only can, can, can use the API gateway to, to validate the, the tokens from the all servers, but also consume those O tokens open ID tokens, send those to the API, to, to, to the policy decision point, make these contextual and more policy policy enabled services, the decisions to actually deal the permit or deny in the process.
So I think these two technologies should actually work together and that in a sense, would, would, would, would solve the issue of role based access control and attribute based access control of API security. That is the, the, the sort of in essence, the, the solution for dynamic authorization for the APIs and with 20 more minutes to go. And that would actually be quite perfect. I, I need to talk a little bit about how we can extend this even to microservices and microservices, as, as, as Alexei, I pointed out, it's a huge thing. Okay. It's not just a simple thing as doing API security. So what I have done in order to be able to articulate how we can apply security to that and how we can have shared services in a microservices environment. I have developed myself a little animation in PowerPoint. Okay. That helps me to keep me on track and not so, so, so lose time or even derail from the subject, but to you, this would look like sort of a cartoon animation movie. I think it is also a crash cord in microservices architecture. So, so bear with me. It's a help for me to get to the point to talk about security in this sense.
All right, we start with the monolith in this case, and in the monolith, there are a lot of services. Obviously the bad side with this was, is one of the services needed to change or needed to update the whole application needed to be updated. So we came up with service oriented architecture. Some I likely 20 years back, but still a very valid deployment approach. So many customers, at least that we talk to still have this architecture in place. Obviously the service month was a, a, a sort of a bottleneck to becoming really agile. We had to take it away somehow. And we, we, we then invented microservices architecture where the microservices were more independently dealing with all aspects of, of actually things that also the service bus was doing. So we now can transformation and security inside the microservice. Obviously there are a bunch of principles and characteristics that are really important that I would think obviously that they are very much micro in the sense of the, the service.
It, it supports meaning that it has a very discreet business functionality. They should be independently developed and they should be able to be deployed autonomously, and they should be able to operate autonomously. These principles are really of course interesting, but, but as with principles, there might be reasons to be a bit pragmatic with certain things. And I will come back to them when we start talking about shared services and shared capabilities inside microservices that maybe some of these principle, at least we need to, to at least take a look at them and see what can we do in order to make things even practically and, and, and sort of deployable and doable at this moment, the first sort of big goal with microservices was to be able to operate with speed. And speed was definitely something that these type of companies were needing. So doing content delivery, streaming media, the focus on speed was high, but with organizations like we normally talk to.
So the, the, the need for safety is more sort of taking up more and more, more of the focus of what we actually tried to do. So speed and safety is something that we really need to, to, to work on. No one ever said that microservices was going to be easy, meaning that if you focus for instance, on, if you focus on this, the clicker seems to me. So if you focus on the single service developing that, that is rather easy today, nobody is debating on how to write the single service operating in a, in a fashion that it is sort of performing to the business requirement. But what happens when you have a, a whole set of systems of microservices, what happens when somebody needs to take responsibility of all the microservices and being able to perform according to a framework of an enterprise here, I see a lot of development going on. And lot of questions being raised, lot of open source initiatives either picked up by companies themselves, or even building their own tooling around how we actually can get microservices to work together.
We are organizing ourselves in tribes or squads. And obviously if you have like 20 microservices, this is one thing. If you are doing DevOps, you are actually being able to scale to even hundreds and thousands. We are using dev SecOps now, and also like say, was within to talking about it, how we can make these operations, the development, even in secure matters. But if you have more than hundred of microservices, you likely need to separate them into various domains. Also, meaning that you might have microservices that fit in a patient domain, some fit in insurance domain, and some might fit in a caregiver domain. These are ways to organize your, your, your microservices. And this will have impact. When I later come to the security part, all micros microservices are consumed and communicated using APIs. They can be developed using various languages, and obviously they can be deployed in the cloud very, very easily. They even have local data management and data management is something that, that also will be addressed by the shared services because data management is one of the more, most critical things in, in, in, in the whole microservices set up, meaning that data can perhaps be, be replicated across the microservices. But then we need tools for that
Last thing I want to point out before getting into the shared services that not all microservices are equal, even looking like a bit like so, but there are some microservices that are focused around one specific function, being able to provide patient information, billing information. There are some microservices being responsible of business process, and there are some microservices being responsible for the channel channel specific microservices that delivers information to an application. And at work, it looks a bit like this. So this summarizes a bit of the, the setup of, of the whole microservices architecture, meaning that we can have an application, a mobile application communicating with one business process, UX microservice talking to two business process management services, cross a domain listing patient and doctor information, and even being able to bill. So this was the, the, the introduction, because I wanted to get to this point.
So if, and should and how we can apply shared services to a microservices architecture in some way shared services, I think somewhat breaks the whole autonomy thing, but it's needed, needed somewhere to F to actually deliver it. And thinking about the system around the microservices, we just need to expand the scope a little bit. Okay. We need to talk about firstly, the data and in order to replicate data, you might need a message broker, okay. Something that can publish and should subscribe data across microservices, truly interesting technology. But what happens when two microservices need shared the same data? This pattern is obviously a big no-no in, in some cases, if you are a fundamentalist or, or an ideal Analyst of microservices, this will never work. But the way I see it, so that the most customers that we have that are building microservices are actually into data management as well, virtualizing database, and still sharing database, actually, because that is needed in order to make these microservices do what they are supposed to do.
Obviously this is able evolution and, and likely perhaps will be replaced by, by local data stores and being able to publish and subscribe this data. But this is truly one of the sort of core services that we have and reason for mentioning it, it is more or less that we, we need to think pragmatically about things. And that is specifically too, when it comes to the, the authorization. Also just shortly, previously, we talked about API management and there is obviously API manages inside the system, but I also talked about an enterprise level API management previously. And I think that that, that these two things are two or maybe two separate things, meaning that the enterprise level or API management can support other services that have already been outside the microservice and the, and the inside microservice, API management tools, or specifically designed to deal with, for instance, also these micro gateways that can recite close to, to a microservice.
So API management is also one of the, the, the core shared services and coming to the two last ones, obviously management capabilities. When I think of management in this case, I, I think of, of containers. I think of doctors, I think of, of how we doing elastic scaling and how, how a microservice can talk to each other. Obviously there is also movement in this market. I, I I've recently been approached by two customers of mine. Talking about a framework from Google called is still though is still, also has a, a notion of a local proxy that can deal with how you can, how each and every one of the microservices can talk to each other. So you can have authentication there. You can have protocol specification, and you can have even authorization inside the management tools. These are pretty well, pretty well interesting technologies, but I think also this, again is plumbing.
This is plumbing that needs to be in place in order to be able to manage all aspects of a microservices architecture, but when it comes to security and especially around authentication authorization and audit, these types of services also is part of the shared capabilities of a microservices. So obviously any oof server, I would say also an attribute based access control service would live there. And an audit service will, will perhaps live inside the microservice environment as a shared service. So, so, so that's, that sort of completes the picture of what are shared services inside a, a, a microservices environment and the whole reason for, for taking this sort of crash course in what it is. And what we can do is that I would like to be able to articulate sort of best practices, even though we are still very much experimental, what can we do and how can we implement dynamic authorization for, for, for these types of services.
And definitely it is work in progress. I do not have any customers that are going live with a microservices authorization strategy, like the one I'm gonna present now, but, but, but nevertheless, that is how the market looks. I think most customers are in the, are presently trying to deliver and design this architecture. So looking to this whole set of the microservices, I see four things that we can do. Okay. The first thing that we can do is obviously implement a very centralized API security strategy. This would apply that it applies to enterprise API management on the top. It would apply to the central API management service inside the microservice. It would also include the all servers and taking the same approach that I described in my, in my API discussion earlier, making sure that the central services of, of authorization role-based access control API gateways would communicate in order to, to make a decision and as early as possible stop and a request that should not happen. Okay.
Also very sort of recently aromatics released a a in this case, again, also a cloud native PDP, meaning a, a, a more friendly deployable authorization service, very small one, only doing one thing, very, very well permitting and denying access at the size of about 150 megabyte. You get a chance to be able to orchestrate and, and implement and, and, and deploy this authorization service to the cloud or to your private clouds. Obviously the whole DevOps process would, would benefit a lot from this because now the authorization infrastructure and the policy configuration can be treated as code, and we actually deployed to your cloud environments. And I think this is a massive improvement that we have done now to, to, to, to be able to, to really make authorization, at least be cloud based. And as I'm pointing out in my third item possibilities now to co-locate an authorization service close to a microservice, more or less being part of the microservice.
And obviously here is also okay, are we not sort of saying that this should be separated? Well, we need to apply pragmatically thoughts here as well. So should the patient microservice actually have its own decision making process? Yeah. Can make sense because the scopes that, that are, that are hit by the patient ID, so that are sent to the patient ID can actually be evaluating using the policy decision language that we have. So we now can send a bunch of scopes to it, a bunch of tokens to it, and the PDP would figure out, give a yes or no decision. It's also the possibility, and I'm not saying that you should do this, but there is a possibility because there are clear requirements to find out this relationship between the patients and the doctor, doctor. And actually you can use this HTTP service connection and ask, is this doctor, this, does this patient have a relationship with this patient simple call?
Yes. Again, breaks the autonomy a little bit a list, but this is something that we can talk about. And I think that it is a clear business requirement to do so. And obviously the last thing, and this is very much working process also, but, but we, we would like to be able to filter not only the single patient record in this case, but being also being. So if you have a patient microservice that also hold all the patient data to be able to, to respond and by redacting or even filtering masking this data, this is working process, but what we are using, we are using some, some JavaScript technologies in order to actually based on the authorization, being able to filter out the payload, coming out of the, of the microservice. These are the, the four sort of obvious, at least this point in time, the, the benefit of using dynamic authorization in a microservice, in an API environment, it's a quarter rather sort of big discussion that I've been been having now. But I was trying to actually focus on taking the API security one step further. So with that, I think I am done in time also, which surprises me a bit and open up four questions. Oh, thank you months, please. A round of applause. Thank you.