Edition 0 Updated to asp. Net core 0

Authorization at Ocelot’s ReRoutes tier.
Ocelot supports claims-based authorization evaluated after 
the authentication. You set the authorization at a route level by adding the following lines to the 
ReRoute configuration. 
"RouteClaimsRequirement":
{
"UserType"
:
"employee"
}
In that example, when the authorization middleware is called, Ocelot will find if the user has the claim 
type ‘UserType’ in the token and if the value of that claim is ‘employee’. If it isn’t, then the user will not 
be authorized and the response will be 403 forbidden. 

---

180 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Using Kubernetes Ingress plus Ocelot API Gateways 
When using Kubernetes (like in an Azure Kubernetes Service cluster), you usually unify all the HTTP 
requests through the 
Kubernetes Ingress tier
 based on 
Nginx
. 
In Kubernetes, if you don’t use any ingress approach, then your services and pods have IPs only 
routable by the cluster network. 
But if you use an ingress approach, you’ll have a middle tier between the I
nternet and your services 
(including your API Gateways), acting as a reverse proxy. 
As a definition, an Ingress is a collection of rules that allow inbound connections to reach the cluster 
services. An ingress is configured to provide services externally reachable URLs, load balance traffic, 
SSL termination and more. Users request ingress by POSTing the Ingress resource to the API server. 
In eShopOnContainers, when developing locally and using just your development machine as the 
Docker host, you are not using any ingress but only the multiple API Gateways. 
However, when targeting a “production” environment based on Kubernetes, eShopOnContainers is 
using an ingress in front of the API gateways. That way, the clients still call the same base URL but the 
requests are routed to multiple API Gateways or BFF. 
API Gateways are front-ends or façades surfacing only the services but not the web applications that 
are usually out of their scope. In addition, the API Gateways might hide certain internal microservices. 
The ingress, however, is just redirecting HTTP requests but not trying to hide any microservice or web 
app. 
Having an ingress Nginx tier in Kubernetes in front of the web applications plus the several Ocelot API 
Gateways / BFF is the ideal architecture, as shown in the following diagram. 
Figure 6-41. The ingress tier in eShopOnContainers when deployed into Kubernetes 
A Kubernetes Ingress acts as a reverse proxy for all traffic to the app, including the web applications, 
that are out of the Api gateway scope. When you deploy eShopOnContainers into Kubernetes, it 

---

181 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
exposes just a few services or endpoints via 
ingress
, basically the following list of postfixes on the 
URLs: 
•
/
for the client SPA web application 
•
/webmvc
for the client MVC web application 
•
/webstatus
for the client web app showing the status/healthchecks 
•
/webshoppingapigw
for the web BFF and shopping business processes 
•
/webmarketingapigw
for the web BFF and marketing business processes 
•
/mobileshoppingapigw
for the mobile BFF and shopping business processes 
•
/mobilemarketingapigw
for the mobile BFF and marketing business processes 
When deploying to Kubernetes, each Ocelot API Gateway is using a different “configuration.json” file 
for each 
pod
running the API Gateways. Those “configuration.json” files are provided by mounting 
(originally with the deploy.ps1 script) a volume created based on a Kubernetes 
config map
named 
‘ocelot’. Each container mounts its related configuration file in the container’s folder named 
/app/configuration
. 
In the sou
rce code files of eShopOnContainers, the original “configuration.json” files can be found 
within the 
k8s/ocelot/
folder. There’s one file for each BFF/APIGateway.