8. Out-of-the box Policies available on Platform

Hi. In this lecture, let us now discuss various out-of-the-box API policies that the Any Point platform provides. Okay, so the Any Point platform currently provides lots of out-of-the-box API policies. To be more specific, the API policy templates used to manage APIs impose some nonfunctional requirements as well as other cross-cutting concerns on the APIs. So let us actually go right into the API manager and start looking into the various "out of the box" API policies. Here we are. So let's pick up our sales order API and enter the API instance for our sales order API. Let's go to the policies and see what all the out-of-the-box policies are that one platform is providing in the API manager. So if you see, these are all various "out of the box" policies, right? and we'll understand them category wise. Okay, so there are some compliance-level APA policies, which are CAs, cross-origin research sharing, and client reinforcement. Okay, these are compliance-related.

We will dive deeper into each of these topics in further detail s in Furth And then there are security-related issues, all right? So, as previously stated, these are all security-related issues involving IP whitelisting, blacklisting, and so on. So, in terms of security, we have authentication-related items such as LDAP Security Manager, as well as basic authentication and so on. And some are IP-based API policies—IP blacklisting and IP whitelisting. And some are threat production-based API policies, like JSON threat protection and then XML thread production and all that. And some are OAuth-related APA policy enforcement. So these are different categories within the different subcategories within the security ithin the diffSo the next one is transformation-related, which is related to the transformation of the payload, request, or response that is coming in and going out.

So this is like transformation and includes things like injection of HTTP headers in the request that is coming in or the response that is going out, or even the removal of the headers. This is basically related to the manipulation of the HTTP headers in requesting our response. And then we have troubleshooting-related policies for some of the NFRS that require logging the message that is coming in and going out with the request and response, right? So there can be logging at the API implementation level in the code, but we can still have it at the APA manager itself. So let's say some requests may not reach the API implementation, correct? The reason for this is that some policies may be violated, and the request may never be implemented. So we will lose such things. So we can enforce this messaging logging so that all the incoming requests and responses, whether success or failure messages, will be logged.

Okay, the next category is QS, or quality of service. The rate-limiting throttled SLA-based ones and the non-SLA-based ones are related to the quality of service. So these kinds of policies are in the quality of service category. OK, so these are different varieties of the policies that we get out of the box. Okay, let's take a look at each of these categories individually. So, let's start with the compliance level API policies. OK, these are compliance-related. Point-platform APIs are classified into two types: client-side idea enforcement and cost-based cross-original sharing. So let us discuss this. So, the client reinforcement, we will look into this in great detail, and again, further down to a proper demo, such as how the client credentials are generated and how a specific consumer can request the client credentials, and how they should be passed via the APA client, such as postman, and hit the request or end point. So we will see that.

But at high levels of client reinforcement, as we have learned many times before in the previous lecture, for every API consumer, there will be a set of client credentials. Okay? So when we enforce the client ID enforcement policy on an API, then the API clients are bound or forced to present those client credentials in the incoming request as part of the TP header or any other place they have to present these client credentials. So, what happens with this particular policy enforcement is that if, say, the incoming request on this API does not have the client ID credentials, then the request will be rejected, saying that the client credentials are is API does nSo this kind of enforcement is for this particular client's reinforcement. So it is compliance-related to make sure that we are getting the request from a known API consumer lar client The second one is cross-organism resource sharing.

Okay? So this one comes into play when, mostly, you think your API is a candidate that can be called from, say, JavaScript applications or web UI applications, right? So I'm not talking about the webserver-side applications, but the web UI, okay? Because it could be a normal high-level programming language calling your API rest and all from the web server side. That is not a problem. So, Cars, if you're into UI-related work or have previously been a part of any UI projects, architecture designs, or even developed, you'd be familiar with the term "cost." Okay? However, if you are unfamiliar with this cost, it is a security concept imposed by the www when applications are called from JavaScript or client-side coding directly in browsers or web us.

So only those exact calls or any calls that happen as http calls or Ajax calls from the browser side, client side, or browser-side JavaScript code should be able to access the resources and endpoints hosted on the same web application ide JavaScriSo, for example, if your hostname is Facebook.com, the general cost principle states that whatever happens behind the scenes in the JavaScript of that entire website, the server side calls can only hit the service resources hosted on Facebook.com. They cannot call Google Cocked sales orders from the Facebook.com website, okay, from the task application, not from the server side. So this is a security-related policy for you. But later on, there are exceptions as well for this because some applications cannot be required to be accessed from JavaScript, right?

So for that, there is this The concept of "crossing research sharing" comes in when the provider of an API, whoever is offering that third party or the external hosting system that is offering an API resource, can say that it is okay for the particular other side to access my resource right from their client side. and they can enable it. And they can put in some rules like "okay" instead of enabling it across the Internet so that anyone can call or be on the network. "Okay, if I get a request from this horizon only, then I can accept the request from the JavaScript otherwise block it," they can say. "Okay, if I get a request from this browser or this IP, I should get a request from that particular host." So there are various parameters, and these are the controls that we can assign to the cards. If you see, I'll just show you a quick one. So, Cars, if I say configure, if I do not say public resource, then it asks, "Okay, public resource." That is, anyone on the internet can call my API, which is fine, but it is something I may not want to do, correct? So in that case, all I can say is "origin," which means what are the lists of allied origins.

So Facebook.com or IP addresses from a separate source are things we can give like that. Okay, so only from those sources will it be allowed. Similarly, the duration of the connection or request connection is not continuous. Okay, once you've received requests, close them. Okay? Similarly, even in the requests that are coming from those particular origins, you may select which methods you want to allow. You might want to restrict access to resources of type from the whitelisted origins, okay? You don't want them to try out any of the other methods. Even if they try, if you don't enable them, they'll fail. Similarly, before using the Get method, you may want to limit to a specific address only.

So, for example, if you know what the fixed headers are for your API because you applied rights and you know that they are the bare minimum address you require and you are not expecting any extra headers from external systems or the world, So because you already know those headers, you can tell that you are going to allow only those headers in the incoming request. This is all security-related, okay? The exposed headers are for the responses. So sometimes what happens is that you are secured, but there will be some response headers that are set from your API that may not be sensitive or may be sensitive. If you explicitly set some of the response letters, they may go out. So to restrict them, you can again say, "Okay, what are the others that are exposed back so that only those addresses will be visible or go back to the client applications that are calling from JavaScript?" All right, so these are the compliance-related APA policies.

Now let us move on to the security-related API policies. Okay, so the platform provides three security-related subcategories. One is the authentication and authorization, which are like HTTP basic authentication and adopt secure authentication, and all. And there is IP-based access control, which involves whitelisting and blacklisting IP addresses. And there is payload thread protection, which is JSON threat protection, and XML thread protection. Okay, so let's look into the authentication and authorization process first. Okay, so among the three, we have http-basic authentication, LDAP, Security Manager, and OAuth. The OAuth one is the most interesting or important one because, in today's API world, all the APIs actually use or enforce the OAuth authentication mechanism only.

So the 20-based API policies have a dependency here. If you want to enforce it, we need to have an identity provider configured for client management. Remember, we discussed the identity manager and the identity provider, the client provider, and the access management. So we need to have those identity providers and client providers set up and available if we want to use this LDAP or the 2.0 authentication mechanism. Okay? Because we're talking about an external provider, we need to choose or say something like, "Okay, my client provider says, for example, Open Am, Pink Federal Rate, or Open ID whatever," right? So whatever we choose, So we have to do that. For example, open Am Access token enforcement requires the OpenAMP Identity Provider. The Pink Federal Federation requires the Pink Federal Entity Provider. Right. So we have to set up this particular entity provider and the client provider in the Access Management section before we can make use of this.

Okay, so after we set up the identity provider and the client provider, and then for these policies, what happens when those identity providers grant the wash tokens for the first time, and when those tokens are provided to the clients? What the clients need to do is comply when we enforce this policy, just like we discussed client ID enforcement in the compliance section. Similarly, once the policy is enforced, APA clients must include this token as part of the authorization in the incoming request. Okay? So, once the request reaches the API manager, this policy will kick in, and it will take that OAuth token and validate it against the client provider or the identity provider again to determine whether or not it is a valid token. So then the response comes back from the identity provider saying yes, this is a valid token, whether it's expired or a genuine one. Then the request gets forwarded to the next set of policies, and if all are good, then to the API implementation.

So, the next secludedrelated one is HTTP basic authentication. So, in addition to the above 20 APA policies, we have this HTTP basic authentication as well, where the APA policy must be linked to one of the security managers, meaning either the point-platform access management itself or some external security manager like LDAP and all. But you know that LDAP is only for the private hybrid cloud, right? not on the cloud hub. For the cloud hub, a proper identity provider, such as OctaSam or others, should be used. So if one of them is that they are configured, then we can use basic authentication so that the username and password will be authenticated against that particular access management profile. Okay, now let's move on to the next ones, which are the thread productions, okay? JSON third production and XML third production are the two production threats. Okay, so what are these ones? What kind of threat production do they do when we say JSON and XML? As a result, these policies protect against attacks that rely on sending oversized HTTP request bodies to an API.

Okay? So this is yet another trend in the attacks that people and hackers carry out. So, for example, they will try all of these distributed service attacks and everything, but almost all of our gateways, Raff, and everything are protected from DDoS, right? So now, since last year, another trend has emerged in which they will not do DDoS, but instead will send one heavy, bulky, or very large sized request to a few HTTP calls or API requests so that it will not be recognised as a DDoS, but the size will be so large that it will crash your server by overloading the memory or consuming a lot of resources and all. How it is applicable for JSON and XML here is that if it's JSON, they can get very big JSON nesting deep down or a lot of array elements in it, big, big string values, and all that. Right, so same for XML as well. So how these policies work is that if we apply or select one of them, they actually ask us what the ideal or expected number of, say, expected container depth is, meaning in your JSON, how much deeper nested capacity you are expecting.

So it's understandable that we won't know the depth right away, right? You may be wondering how we know how deep it will be before we implement the interfaces, see the canonicals, or see the data structure. True, I agree. So this could be an effort applied in the middle of the project or just a few months before starting the project, okay? After analysing the logging or your payloads in and out and everything in your logging framework or somewhere, you can come up with a reasonable number, right? So saying, "OK, no matter what, this is the maximum debt," or if your organisation has a mature canonical model because you have to define your Ramble before any project, correct? As a result, the Rambleschemas will function as a request and response card. Without it, you're unlikely to begin your development, right? You must have your definitions first. So from your design phase, it's also early in the project that you may come to know, "Okay, these are our schemes to know where we have seen this much depth."

So you can give a reasonable number, extrapolate or double it, and give some numbers. Similarly, the maximum length that is allowed is the number of key-value pairs in the JSON, the maximum number of object entries, the length of the object, and if there are any, how many maximum errors you allow, and all these kinds of restrictions you can give, then what happens is for the incoming requests, which have the APIs have this particular threat production policies, whether it is JSON or XML does not matter.

Then those request payloads are validated against these settings and we see, OK, if they have or meet all these restrictions, then only third. This way we can avoid the threat that is supposed to hit the API behind the scenes. All right. Now, the next one is the quality of t payloads areSo the quality of service is currently provided by a platform, which includes rate limiting, throttles, and other features. So rate limiting is actually what it does; it rejects the request when the throughput limit has been reached. Okay, so you know this already. So when we give out like 100 requests per second or minute, if that throughput crosses the number of requests by more than 100 in that particular minute or second, then the requests are rejected. Okay, so this is the rate-limiting one. And what do you think? What is the difference between the SLA-based and the non-LS? Because both are acting as rate limiters, right?

Yes, there is a minor distinction for non-SLA-based rate limiting, so what happens when the throughput limit is defined in the APA policy definition associated with the specific AP instance? Whatever 100 or 200 bits per second we enforce for that APA instance and the sum of all of its APA clients, ignoring the identity of the APA clients, will be calculated. You got it right. In an APA, for example, there are ten consumers. So one could be customer one and another could be customer two, and one could be LB one and one could be LB two. Okay? There are many consumers consuming this API and making calls. So if it is not SLA-based, then what it means is that this 100 requests per second is applicable to all those consumers. So, if one consumer hits 50 times in a second while the other five only hit 20 times, and if the maximum has already been reached by all of them, he's already hit 100, then all of them will be affected. So that fifth consumer who may think, "Okay, I have only done it 20 times; why is it throwing me off?" Okay, that's because it's a shared SLA.

It's a shared policy. Whereas for the SLA-based, it depends on the SLA ached 100, When I say SLL, it does not again mean that it is for the individual consumer, but it is a slow tyre e it 20 timRemember we discussed silly tyres where we can create some tyres like the basic Gold Platinum tyre and say, "Okay, for the basics, 100 requests per second is the limit?" For gold, 1000 requests per second is the limit. And for Platinum, 10,000 requests per second is the limit. We can do this so that each consumer, regardless of whether they subscribe to or fall under a specific SLA, has a different limit. That is the difference between these things. The next set of API policies is now complete. This is the transformation one, okay? So the transformation ones are basically about the injection or removal of the HTTP headers, okay? So you may have some things like, once the request hits the API, before it hits the API implementation, you may want to inject a particular HTTP header for informational purposes, logging purposes, or some analytic purposes, right? So such header injections can be injected on the fly and do not come from your API clients.

Okay? And there can be a scenario where you want to remove it as well. So, like we discussed, there are two ways to remove cars; yes, you saw that we can remove them. However, in practise, there is a different concept where you can restrict the addresses that cannot be given out and expose only a few. Similarly, you may not want to expose all of your response addresses back to non-Carson clients or any client. Okay? So you may want to expose only a few of them. So you can remove all the unwanted ones on the fly by enforcing this particular policy. And troubleshooting is a straightforward process; you already know what it does. This is your message logging, all right, so these are the different types of policies that come out of the box and you can enforce on the API instances just before leaving. Let us discuss a little bit about this. Solitaire, I know you understood the concept when we said basic. Gold and platinum are just like any other metal.

ITE project where we saw what is basic gold and platinum means like kind of extra fish will come from platinum and gold and basic has some limited ones. Right? But first, let's talk about it. So the seller tyres are similar to the APA platform, which supports these tyres to enable different classes of APA clients, as previously discussed. So APA clients, or any client, can come in and request and receive access to an APA. But while getting access, they can choose which type of access they want. If we have created some tyres so far, there are no silly tyres on the sales or experience AP. But let's say I'm going to create something. I'll say, "Okay, I have a basic tire, "normal tire," for which I'll say "auto approval," because I am not going to give any features in this.I don't mind having automatic.

I don't want to again introduce an approval for it. But I'll only pay $100 for a minute. Okay. This is very little, right? When we put it on a public portal and many developers from all over the world try to do it, they'll get a lot of requests. But it is fine. Okay, I'll just add it. Now what I'll do is give one as a silver ticket, and I'm going to say I want to approve this. I don't want anything automatic. And I'll say 1,000 in a minute. Okay, apply. Then there's one more level. Let's say gold. For time constraints, reasons, or gold, I will not go to platinum. And I'll say manual; this one will give 10,000 per minute. add it. NSo what happens is when someone accesses the consumer's access to the API request at the time, they will be presented with the option to select one of the tyres for which they were requesting access; they can select the one that they like, and accordingly, that particular client, the consumer, is classified as the particular tyre of the consumer.

Okay. He's a gold tire, he's a silver tire, or he or she is a basic tyre consumer and all.So if an AP instance has the silly tyres defined, then every AP client that registers for access to that AP instance is assigned to one particular asset. They cannot select more than one tire; they will be assigned, lowering the level of service quality. Okay? The gold level If they choose the gold level, they will receive a higher quality of service based on the number of requests, and so on. Okay, so this is how the throughput and the ratelimiting can be controlled by your own tyres as well. Okay? Customers and providers alike can monetize this if they so desire. But even if they don't want to monetize, if they just want to control traffic from different types of tires, this slot tyre feature allows them to do so. Okay, so this is an elaborated detail of the various "out of the box" policies given by the API platform. Let us now go to the next lecture, where we will discuss the customs policies. Alright. Happy learning.