 Hello everybody. I'd like to welcome to our next session, FineGrain API authorization is in three scale and authorization system. My name is Sergio Canales, and it's my pleasure to introduce our speaker for today's session, and I'll have it solid. Feel logistic before we get started. If you have any questions during the session, please submit it in the chat, and we will try to cover at the end of the session. Or we will make a point to follow up after the event and the presentations. For the recording, all the sessions today will be available in the event hosted on YouTube. So you can have the opportunity to check after. Also, I encourage you to use the live chat during the break in the main stage. You always have the opportunity in the main stage to retake and have some exchange. And with that, let me turn things over to Abdel Hamid. Yeah, so welcome everyone. It's great to be here, and thank you for joining us today in the definition event. So my name is Abdel Hamid Shulaiman. I am a solution architect in Red Hat. I work in a media team as a specialist in ABI management and Red Hat integration. We have an exciting talk for you today on fine-grained ABI authorizations with a series-scale ABI management. So I will talk about the centralized authorization systems. Basically, we have two authorization systems. I will talk about the first one is key clock authorization service. So I will describe how to integrate it with a series-scale ABI management using a custom policy. And the second one is OBA or Open Policy Agents. So I will describe how to integrate OBA with a series-scale ABI gateway using a custom policy. So by the end, we will have a demo and the questions and answer. So by the end of this talk, you will know how to use and configure these policies in a series-scale ABI gateway. So let's begin by looking at O was the top 10 ABI security. So if you are not familiar with what this top 10 is, the Open Web Application Security Project is a non-profit community that produces best practice for web application security. So the whole idea is to improve the security for web applications and the area of ABI's. They do the same. So they have analyzed number of security incidents related to ABI's and they come up with a head of top 10. So starting from number one being the most widely seen vulnerability. As you can see here, four of them are related to authorization which are in getting caught up. So which need to be mitigated by organizations. So I will not go into details of those vulnerabilities, but I will discuss how to solve it in terms of authorization. So to prevent the authorization of vulnerabilities, you of course need to implement authorization logic. But before that, I want to take a little story. So 20 years ago, everyone was building their own authentication system. So I remember that everyone thought it's easy. So we need just a stable user name and password and we will build our authentication system. But what ended up, it requires more sophisticated requirements like email verification, like for example two-factor authentication, like hashing algorithm. So which at the end it lead up to challenges with consistency, a challenge with security and a challenge with scalability. So that's why most of modern applications use centralized authentication component like identity management solution or key clock. So all of these reasons apply also to the authorization and challenge. So in the left side here in the source code, we have a quite simple condition, if it's just if condition, to check the rule-based access control. We have only users granted a manager role can access the protected resource. So what would happen if your requirement changes and you need to access the same resource to a specific user name or even you want to include admin role to access the resource. Or perhaps you want to leverage another access control strategy like AVEC or attribute-based access control. For example, check the time, check the user context to allow access to the resource. So you need to change your code. You need to deploy your code. Because here the code is, the authorization logic is tightly coupled inside your code. So in the right side, we don't have any reference to a specific access control mechanism. So access control is based on the resource you are protecting and your application is only concerned with the donations granted by an external authorization service. So this is a concept of centralized authorization which allows you to externalize the access management and decisions from your application using an external authorization component. Alright, so, but what are the benefits of using centralized authorization component? So in a distributed systems and the micro-surface architecture, we will have many ABI's, many service which become hard to manage and to operate. So using centralized authorization, the administrators can easily define and enforce access rules from a central location which will simplify the access management. With also a centralized component, of course, you will have simplified admin operations where the administrator can efficiently manage the user access and permissions from a web console, like a key clock web console for example. Also from the security team perspective, it becomes easier to do security review for permissions. So they can review access what are their responsibilities for, so they can check for compliance, for example. They can make sure, for example, this organization doesn't give access to credit card data unless the user is secured or has two-factor authentication. So it becomes an easier for also auditing and compliance. And from developer perspective, they can build the application faster as the application code is decoupled from the authorization rules. Which is make the code changes can use, they can push, it changes quickly without even checking security. Alright, so let's hear, have a look about city scale high-level architecture. We, city scale has basically two components. The first one is the ABI manager which is a control billing and configuration management component. So ABI provider can use as admin portal to create an ABI product to configure policies to view analytics, to monetize ABI's and to manage content of the developer portal. And the ABI gateway is a runtime component that is deployed between the consumer application and the ABI backend to act as a reverse proxy so it can protect the ABI's backend. And the goal here for the ABI gateway is to enforce policies. So policies like reclimiting, authentication, authorization, content caching, dynamic routing and the others. Also it can have some sort of cross-cutting concern like logging and auditing. Besides that we have the developer portal which is used to socialize the ABI to ABI consumers and do a self-service like registration, documentation, half of all the ABI's. So they can easily discover the ABI's. All right. So 3D scale ABI gateway which we named ABI test has a policy framework. This policy framework allows the developer to have a custom logic to deploy the custom policy in order to extend the capability of the ABI gateway using custom policies. So policies can be written in Lua and deployed to ABI gateway. Also the ABI gateway has built-in set of more than 40 policies as ready for only configurations without any coding. It's out of the box capability inside the ABI gateway. All right. So but in terms of the authorization capability in the ABI gateway, the ABI gateway itself has a policy to manage the authorization in the OpenID Connect which is GWT, a clinical check policy. And this policy uses the token-based authorization concept which is based on a validating token and using information stored in the token to decide if the access should be allowed or denied on a particular HTTP resource. So in this example, if the user is administrator or has in the token cream has a role called admin, he will allow you to access the resource. But we want our objective here is to decouple policy decisions from the ABI gateway as it strives issues in the micro-service. So as pushing all the authorization decisions to ABI gateway can quickly become harder to manage in complex ecosystems with many roles and with many access control roles. So from design pattern perspective and best practice, the ABI gateway should be a policy enforcement point where the authorization system should be a policy decision point. So that we need to have an integration between the ABI gateway and the authorization system which I will describe in the next section. All right. So in the next section, I will go through the key clock authorization service. So if you are not familiar with key clock, key clock is a popular open source identity and access measurement solution. It's designed for modern applications like single-page applications and for APIs and the micro-service. It's also designed to be nice and easy for developers to use. It has support of many standards, protocol like OpenID Connect and SAML to secure and authenticate micro-service and APIs. It also can read users' data from different sources like database or LEDAM and others. It has also capability to do identity brokering to delegate authentication to external identity providers like logging with a social network like Google and Facebook. And it has also more features. But one interesting feature here is the authorization service. So key clock provides a module or a feature to allow you to define fine-grained authorization routes. All right. So key clock authorization service are built on well-known standards protocol like OSU2 and user-managed access specifications. Key clock provides fine-grained authorization service in order to define access control. So here it consists of different objects. So the first one is the resource. You basically need to create the resources. So the resource here is the object being protected. So in case of risk area, it might be in the point. And after you define the resources, you need also to create a scope. So the scope is what can be done with a resource. So you have, for example, a REST endpoint or a REST resource. So you can, for example, have a scope for view, for HTTP method view or for delete method to delete resource or for update methods in order to edit the resource. After you create the scope, you need to define the policy. So the policy here is a condition that must be satisfied to grant access to a resource. So policy might be based on rabbit or road-based access control or it might be based on a context or it might be based on attribute-based access control. So you can have a condition like the user time or the time allowed to access the resource or also you can have flexibility to create a JavaScript to define a policy based on JavaScript. So after creating a scope and the resource and the policies, you need to correlate those objects together which inside the permission, so you create a permission and you associate the resource with the scope and one or more policies. And the authorization service also provides a REST EBI so you can integrate with it using the REST EBI. So in the REST EBI you identify, for example, the resource and the scope and the token and the particular authorization service will provide you with a decision either to allow or deny the request. So in the course management use case and this use case which we will use through the demo and other slides, we basically have to actor the student and the teacher. So teachers only will be allowed to delete a course and both the student and the teacher will be allowed to view courses. So when designing REST EBI of this use case, you will have a course resource with two HD methods. The first one is the get to actually review the courses and the second one is delete method to delete the course. So as we are talking about series scale and we want to integrate series scale with key block authorization service, so we have a community policy which is existed in this GitHub repo which is written in Lua. So after cloning this label and installing this policy into the EBI gateway, you can have this kind of architecture. So let's begin with the end user. So we have here the teacher, the end user, is trying to use mobile application or web-based application and the application which uses series scale EBI gateway which is configured here EBI product to secure the course surface by end using OpenID Connect. So key block here acts as OpenID Connect provider or also two provider and also it acts as an authorization module. So once the teacher provided his username and password or authenticated through the application and the key block, he will have here a token, GWT token. Then the application will use this token for each request to the EBI gateway. So if the user tried to delete the course, then the token will be attached to this HTTP call to series scale EBI gateway and the series scale EBI gateway will have deployed the policy of key block authorization policy. This policy will check the HTTP resource against the configuration for defining a key block resource and the key block scope in order to send an authentication request to key block authorization service. So it will send a key block authorization request attaching the resource and the scope. Then key block will respond with either true or false. So based on that the EBI gateway will allow or deny the request based on a decision determined from the key block authorization service. So in this architecture, key block acts as a policy decision. On the other hand, EBI gateway acts as a policy enforcement. All right. So as I described before, in order to configure key block authorization service, we can use the admin console of key block in order to create artifacts inside key block authorization service. So in our use case, you need to create the course resource and you need to create two scopes, one for delete, other for get. And you need also to define two policies, one for students and second for teacher based on rule-based access control. And after that you will create a permission. So you will create a delete permission in order to attach each resource and scope and policy. All right. So also you need to configure this policy inside series scale. So you need to correlate your HTTP maybe in rule to key block resource and scope in order to allow the policy to call the rest EBI of key block to check the authorization. So here are the configurations based on the course management use case. All right. So in the next segment, I will describe another authorization component which is an open policy agent. So OPA or open policy agent is an open source general policy engine. It actually has a concept of policy as quote where policies are written in declarative language called repo. So OPA also evaluate the policies against input data to check if this user is allowed or denied. So the decision of the OPA might be based on definition of a policy and also definition of an input data. So in order to integrate series scale EBI v2a with OPA we need a policy. So this policy also existed in this GitHub repo. So here is the flow of OPA. It's similar to key block flow. So we have here the end user. End user wants to authenticate first into the application where the authentication will be through key block. So key block here act as an open ID connect provider. After the authentication the user will have a token into the application then we will attach this token for each EBI request to the EBI gateway. And the EBI gateway will be configured with OPA policy to integrate with OPA through HTTP call. In order to get the decisions from OPA. But this policy need to send some data from the request to OPA to OPA policy. So this input data are based on it sends all the message body and all headers attributes, all query strings and it sends also the pass or URL, URI which is input. And based on the decision it will either allow the request to the policy surface or it will send for Zim3 or unauthorized HTTP response to the client. So again in this architecture OPA engine act as a policy decision. On the other hand the EBI gateway act as a policy enforcement. All right so to configure this policy in series scale it's very easy to configure so you need to provide the URL of the OPA policy EBI and optional you can have an error message to return to the user. All right so here is an example of a RICO policy. So as our use case we want to allow only the teacher to delete a course. So in this policy you need to check if the HTTP message is deleted and if the input resource code is course and then you need to check the GWT claim. GWT claim has a role called a teacher. If that is allowed so the request if that is true the request would be allowed and the OPA would attempt as a decision to do the EBI gateway. All right so now we have two policies in GitHub Reboot so we need to install it to our EBI Cast. So as the Reboot describes the steps but here I am just describing quickly. So of course you need to install an EBI Cast on OpenShift using the operator so you need to install the operator from the operator hub. Then you need to create to connect the gateway to the EBI manager using access token. So you create an access token in the admin console then you create an OpenShift secret in order to allow the EBI gateway to access the EBI manager. Then you create a secret for the policy so in order to store the source code or the loophiles into the EBI Cast. So you create a secret that contains only the loophiles and the policy code. After that you create an EBI Cast CR where you create an example for an EBI Cast and optionally you create a custom policy definition CR in the EBI Manager in order to view the policy in the admin portal. You also order to allow the admin portal to render the policy configurations. Alright so in the last segments I will go through the demo. So the first step I will show here is the key clock. So I will show here the configurations of key clock authorization service. Here I have inside my clients I have inside the client I have the authorization option. Inside the authorization tab I will have all the resources which I described. So I create a resource called course then I create two scopes one for get and other for delete. Then I created policies one for students and second for teacher and both are from type role. Then I attach the policies with the scope and the resource into the permission. So here the permission is just kind of attachment. So here is for example the delete permission where I attach the course resource with the scope delete with the teacher. And also key clock authorization service has a nice feature to evaluate your artifacts and your definition for your authorization rules. So for example I created two users one for students and second for teacher. Let's check here the students. So here is a user called the students and the scope the resource of course is the course and the scope I want to check is a delete and get also. So this evaluation will it's just for testing. So after you develop your rules you can use this evaluation in order to test the decision. So you see here I have here I am allowed to as a student to get the process and I'm not allowed to delete the process. So this concludes key clock configurations. For series scale here is the admin board for series scale. I have here product called course management. Inside this I brought it protects a back end called course management. These ABIs are the URL of the back end which is the ABI between products and the ABI product is configured to authenticate the user using open ID connect protocol with retouching sign on or key clock provider. In terms of policies here I added as a key clock policy with the configurations of the key clock resource name and the key clock scope for each URL mapping. So we need to have a relationship between a resource, HTTP resource or HTTP URL mapping with HTTP verb and with key clock resource and method. So these configurations describe it. And in terms of mapping rule I have here the course you are also with two verbs get and delete. So I can from deploy to my ABI course and test it in software. So let's use a testing tool to order to send a request to a series scale ABI gateway. So I use here a tool called bus demand. Bus demand a very famous tool in the ABI. So in the authorization here I need to have a token to get a token in order to access the ABI. So let's get an access token. So I need to authenticate. Let's try to authenticate with the user of a student. After authentication I will have a token. This token, bus demand will attach it to the header for the request to the ABI gateway. Let's test the get courses. So get courses return successful with just some response as I am allowed to get a course. So let's try delete a course as a student. So here is the delete. As a student I shouldn't be allowed. So here the ABI gateway then falls usually with an error message in support. So here we are able to test the policy using bus demand. So in the last segment I will receive your questions and if you have any questions please let me know. All right, no questions. So at the end we learned the concept of centralized authorization systems and we learned how to integrate key glob authorization servers and OBAO is a city-scale ABI gateway using community policies. And I would like to thank you very much for attending this session and I am happy to receive your feedback about the policies and if people have any questions. Thank you very much Abdel Hamid. We were looking at the chat quite for now. We don't have questions so we are pretty much closing. We are on time for these last moments. Maybe a question from my side that I work on consulting. Any tips or any recommendation by people who is starting with this because this is like a new way to work. A lot of people need to integrate with this. So maybe from your experience like any good things or maybe things to avoid. Yeah, so I totally recommend starting by looking into the authorization code into your microservice and to start using the key glob authorization service with assemble rules like rule-based access control or any simplified approach. So you start defining your roles across applications. You start also with designing your authorization solo application. Then you can apply this idea of centralized authorization. So you can apply it if you are using Quarkus or if you are using Spring Boot. So Quarkus provides plugins and libraries to integrate it with the authorization service. Also I talked about integration with the API gateway like CDScan. So others also the API gateway can be also integrated with the Quarkus authorization service. Good. Wonderful. Thank you very much Abdel Hamid. So we're pretty much done here. I want to thank you. It was a wonderful presentation. Thank you everyone for joining us today. We hope that you enjoyed the session. You can reach us anytime for further questions. You will have the recordings on YouTube. So anything new you can always reach out by email or maybe any social contact. That is Abdel. A reminder that the other session will be available soon. Be sure to stay for the next presentation. And hope over in the many stages to see all the session that is starting right now at the same time. So thank you very much for your time and see you next time. Bye-bye.