Let's look at configuring policies against the API requests. First thing let's look for an existing policy. So as we've said we've got different scopes. If we go to the products and we go to starter, we can see those are policies listed here. We can see there's an inbound policy which limits the number of calls and renewal period. If we go to Postman and we just run this one, two, three, four, five, this time should fail and indeed it does. So we see the rate is limited, try again in 54 seconds with the 429 request and 47 seconds. So that's counting down for us. That was an easy way for us to see how this policy has been applied to our particular subscription. 

Next thing we do is we want to look at perhaps changing some other policies, maybe an outbound policy. So let's go back here and look at the API and we want to change the Demo Conference API. This is specific to this API. We want to change all operations, and we want to add some outbound processing. We're going to try to use the UI here to change some headers. We've got the outbound policy and we want to choose set header. So let's go find a header to change. 

If we rerun this request here, and look at our headers, let's say we don't want anyone to know what the version of AspNet is. So let's grab that, there. And we want to delete it. We also want to delete the powered by ASP NET. Add header, delete, delete, and save. Cannot have values, sometimes these get populated with a value. You just need to delete it. If we go and write our query again that's already saved, we can see those headers have disappeared. So that was very easy to manipulate or control the data coming back from the API. 

Let's say we want to try something a little different. We want to go and edit this policy manually. So rather than choosing this we can choose this button here, choose expand, and we want to do a find and replace. We want to basically replace all the URL CORS that reference this conference API website and send them back to our website. If we scroll down here we can see all the different types of policies we have. In our case we wanna do the find and replace string. So what do we want to find? We want to find anything that says conference, API, azurewebsites, and we want to replace it with our URL. We'll click save.

So if we go and run the Postman call again, we can see that's now changed. So we've applied two policies, three policies, to the outbound processing of the API request and we've applied this to all operations. So let's say we want to change one particular operation. If we go to get sessions and we want to add a new policy, you can see here we can choose other policies. We want to add an outbound policy here and we're going to look for JSON TO XML. So we'd like to convert the JSON output to XML for this particular function. So if we click save and go to Postman, let's try to run that again. 

We're still getting back the JSON version of the code. If you wanted to troubleshoot this, there's a method for doing that. If we go over to the test, select get sessions, and send the query, we can then click the trace button here. So as much as we've got this response, we want to know why that policy hasn't applied. So we can see the total response time, and we have different sections we can jump to.

So let's look at the outbound section. The reason that we can see that here, is the content type. It's not applied. We can see the other policies that we did apply worked. All we need to do in this case is go to the design for that item, and we're going to change these two values to false, and save. Now if we try this operation and test, click send, we will look at the trace again and we're hoping to see that the JSON to XML has been applied. Outbound, and we can see that it was set to XML which is exactly what we want. We can validate this by resending the request, and we can see we've got a different style of return. 

If we save this query, and let's duplicate it. We're going to call this one speakers. Change the COR there to speakers. We can see we're getting JSON from the speakers still, and we're getting XML from sessions. Effectively applied policy at different levels to manipulate the API request in different ways. The very next thing we want to do is apply the policy to look for the correct token. We've seen that we can validate the token, but we're not applying that to our session. 

So again on the Demo Conference API, all operations, I would like to add a new policy. We're going to go into the code editor for this one and expand. On the inbound policy I would like to validate the JWT token. We need to delete some of this code. We're going to delete the issuers, audience, the claim, the particular claim we're going to match as audience and the audience value is the backend application. In the token it will decode it, and we're looking for this value. We're going to call this auth, and let's just change the message here so we know that it's us, and we need the endpoint that we're going to validate that token against. We captured this earlier from Microsoft here. 

Now there's only one problem with the endpoint that we got, and that's it's version two. We just need to remove the version two and you may also know that you can swap out these values here. If it wants to be more readable, instead of the tenant ID, you can put in your cyberlab's name there. So let's grab this openid connect inpoint for validation and put it in here. Don't forget to leave the html closed, and save. 

Now we've applied a lot of policies here and we're maybe not sure exactly what order they're happening in. What we can do is calculate effective policy. If we choose a particular product, you can see the effective policy view. Here we can see the rate call limited, which was on the product. Different versions are there. If we go and check this against the sessions and we edit this one we should see that particular policy for the JSON to XML call as well. So there's our oauth, check, jwt token, check, the rate limit, and outbound policy. We're doing the final replace JSON to XML and removing the headers, so this helps you view all the different policies in one place. 

Now let's test if our policies worked. We'll try the developer portal first. Jessica let's give it a refresh. We're in the get sessions authorization code. Let's have a look at the token just to make sure we've got the right user. So we have Jessica@mycyberlabs, and we're going for the backend application. Let's click send. We get a 200 response okay. So we've successfully applied that validation code there. If we turn auth off we get the authorization failure, you are not allowed in. Which is good. 

Let's go to the Postman application, and we've got our speakers and sessions. We're gonna say get new access token. We're gonna call this Jessica, and request a token. Let's grab this token and prove that we are Jessica, no slight of hand going on. Jessica@cyberlabs on Microsoft and our audience is the backend application. 

If we go back to Postman, we can then choose the token Jessica and preview the header. We've then added this token to this header here and we click send so we get a result. Let's take this to the sessions header. We're gonna send as well. You're not allowed in. So make sure we've got the latest Jessica token and send, and we get our result. So if we were to remove this token from the header, and send, you are not allowed in. So we've successfully secured our API with a validation policy and we've tested that and validated that token for that user works. 

This concludes the course, and the demos. I hope you've found this useful. I've tried to include steps here that help with troubleshooting. The oauth token flow is definitely difficult and without some of these tools it's difficult to troubleshoot.