 Hello, everybody. This is Claudio Covey speaking again. In our last video, we will implement a basic access control policy based on octas, groups, and claims. OpenDConnect claims, according to the official specification, are a piece of information asserted about an entity. Name, family name, picture, etc. are claim examples for users. On the other hand, OpenDConnect scopes are a group of claims. So, for this fourth video, we are going to define a new claim based on an octa group. The claim will be included in all scopes defined. On the other hand, the Connect OIDC plugin, to allow the con-route consumption, will check if the coming tokens have these specific claims included. Only users who are part of the octa group will have the claim included in the token, and therefore, will be able to consume the route. So, let's check our octa configuration now. First of all, I have created two users in one group. Here are my users, and here is the con-group. And as you can see, the group has only one member. Again, the new claim will be based on this group. So, only its members will have permission to consume the con-route. And here is the new con-claim definition. It is based on the con-group, and is going to be included in any scope for each access token issued. So, now let's run a token preview to check the tokens and the claim out. For the first request, I'm going to use the user who is not a con-group member. The octa application is the same authorization code we used before. Grand type is authorization code. And we're going to use the standard open ID scope. As expected, the access token doesn't have any con-claim inside of it. However, if you use the other user, since he belongs to the con-group, the access token will be different. Here's the con-claim inside our token. Now, let's check our con-route with the OIDC plugin enabled. So, here's the service, the version, the route. As you can see, the new parameters are saying that the plugin should check if the token has the con-claim with the fine and octa. So, in this sense, the route should be consumed only by users who are members of the con-group. Now, you're ready to consume the route using both users. Similar to what we've done in octa's token preview process, for the first request, I'm going to use the user who is not included in the con-group. As expected, we shouldn't be able to consume the route. We'll try to consume the route, but since we don't have any token injected inside our request, the API gateway is redirecting us to octa so we can present our credentials. And after getting authenticated, octa is redirecting us back to the API gateway. However, since the token doesn't have the claim inside of it, the gateway won't allow us to consume the route. And now, let's use the other user who is member of the con-group. Again, we try to consume the route, getting redirected to octa, but this time we're going to use the second user. Again, after getting authenticated, octa is going to redirect us back to API gateway. However, this time, our token has got the con-claim with the fine in octa previously. As a matter of fact, if we go to JWT.io website, we'll be able to decode the JWT token and check the token and the claim inside of it. That concludes the last video of our series. I hope you have liked it again. Thank you so much.