We have architecture pattern (Layered DMZ) where:
1. External facing applications are deployed in 3 layered DMZ (DMZ1 for Web Server, DMZ2 for App Server and DMZ3 for Database server)
2. We do not allow DMZ1 directly talking to LAN, however DMZ2, DMZ3 can talk to LAN
WSO2 API Manager will be installed in LAN, the issue is how do we expose services from LAN API store to external world. Which design pattern is best suited for this? I have couple of options
Option 1:
Deploy another instance of API Manager in DMZ1 which 3rd party can access
Deploy set of services in DMZ1 API Manager only for 3rd party access
Have reverse proxy in DMZ2 which talks to LAN server
Option2:
Single instance of API Manager deployed in LAN
Reverse proxy in DMZ1
Forward proxy in DMZ2 (which currently we do not have)
Forward proxy talks to LAN
I remember IBM has virtual/physical Datapower appliance which acts as ab external API gateway, how do we achieve similar design pattern with WSO2?
Many thanks in advance
WSO2 API Manager will be installed in LAN, the issue is how do we expose services from LAN API store to external world
WSO2 API Manager has a component API Gateway. Actually todays there are two ways to do that
Use API Gateway
API Gatway is an instance of API Manager with parameters specifying, that the instance is a gateway, so other modules (key manager, store, publisher) are disabled or not used
We use API Gateway in DMZ. This instace will authenticate and authorize the calling clients. However, the gateway still needs to call KeyManager web services for token validation and the publisher needs to call gateway for API deployment
(KeyManager and publisher are the services in the APIM in LAN)
Using API Micro Gateway
Needs to be deployed as individual modules and are able to validate client's tokens (jwt tokens) even without any connection to the LAN instance
Note: When not using static api keys, but OAuth authentication, then you need to expose a route to the token and revoke service
Resources:
https://docs.wso2.com/m/mobile.action#page/97564467
https://apim.docs.wso2.com/en/latest/Learn/APIGateway/overview-of-the-api-gateway/
https://wso2.com/api-management/api-microgateway/
There are several common deployment patterns recommended by WSO2 for API Manager which can be found below.
https://docs.wso2.com/display/AM260/Deployment+Patterns#DeploymentPatterns-WSO2APIManagerdeploymentpatterns
You can go for pattern #4 or #5. Pattern #5 will keep your total cost down in terms of license fee and infrastructure fee.
Related
I've created a SOAP Service in ABAP, which perfectly works inside the network.
Now I wan't it to be called from outside and I haven't really found any tutorial.
Most likely a SAP Web Dispatcher or a reverse proxy is required, but how to use them?
Or is there an easier way to make the endpoint "public" and callable from the "outside"?
Making it public not part of SAP system. You need to configure your network to allow incoming request. Generally you need to configure your firewall. You need to open a port on firewall and redirect it to your SAP server http/https port. It will also create a risk for opening http/https port to outside. You must sure about limit your your web service user authorizations and changing all default passwords and using update date SAP system for security patchs.
For more get security I prefer to use a proxy server like nginx/apache to just serve your SOAP service over it.
Usually it is done thourgh reverse-proxies, to minimize risk of attacks from public Internet.
The general schema looks the same, although there are multiple variations depending on the company
The oldest and the most traditional reverse-proxy for SAP systems is a Web Dispatcher
SAP Web Dispatcher it includes load balancing and HTTP filtering
https://informatik.rub.de/wp-content/uploads/2021/11/2_sap-secure-configuration.pdf
https://wiki.scn.sap.com/wiki/display/SI/FAQ+Web+Dispatcher
https://blogs.sap.com/2021/05/09/landscape-architecture-sap-web-dispatcher-deployment/
SAP Gateway is a framework for exposing functionality as REST/SOAP web-services
https://blogs.sap.com/2018/04/15/sap-odata-service-get-consume-rest-service/
The tutorial for configuring SAP Web Dispatcher + SAP Gateway together
https://help.sap.com/saphelp_uiaddon10/helpdata/en/ec/342f1809c94d2b817ba772fe69e43f/content.htm?no_cache=true
The other options for reverse-proxy for SAP:
nginx
Apache
...
You are free to choose any reverse proxy on the market depending on your environment.
Anyone can tell me what kind of service fits on this use case below:
I want to expose a public IP that receive HTTPS/HTTP requests and forward the traffic to my services I have in on-prem.
Looking for Azure, AWS, etc, etc, are there some service that serve to my problem?
Regards...
If you are using using Azure and you want HTTPS based request to be sent to your backend APIs (which can be on prem or on any cloud) you can check for Azure API Management (APIM).
You can use the APIM with or without VNET.
APIM can be used in External Mode if you want to integrate a VNET to perform data plane operations which will expose a Public IP as well as a Gateway URL which you can be used to send HTTPS traffic.
Reference:
https://learn.microsoft.com/en-us/azure/api-management/api-management-using-with-vnet?tabs=stv2
https://learn.microsoft.com/en-us/azure/api-management/api-management-key-concepts#scenarios
Additionally, you can also check out Application Gateway
Reference:
https://learn.microsoft.com/en-us/azure/architecture/example-scenario/gateway/firewall-application-gateway
and trying to deploy micro-services build in spring boot on aws but didn't know which aws service is suitable for perticular spring micro-service(Could Config, Service Discovery, Api Gatway, and vault).
I build an api gateway service on spring boot, but when it comes to deployment on aws i got confused with the aws api gateway.
Do we need both of the to work together? or we can just setup springBoot Api gatway on ec2 instance.
And its out of context but, do we need separate ec2 for small service like 'Service Discovery', 'Config Service' etc.
thanks
API Gateway is just a kind of routing to your application, no matter if it is hosted on serverless platform or on EC2 container.
You can try to deploy your Spring Boot app on AWS Lambda environment and this way you don't have to think of configuring the server environment. You have to be awarded the cold start of the application in this case. You can google more about it how to solve this problem.
API Gateway is like facade in front of your microservices for communication with external services. There are several ways to use/implement API gateway depending on requirements such as Request Routing, API composition(calling multiple services and combining responses), Authentication, Caching etc.
AWS API gateway is good if you need request routing feature but it can't perform API composition. In such case you need to implement your own custom API gateway using technologies such as Spring Cloud Gateway & Reactive programming.
GraphQL is another popular technology to implement API Gateway.
P.S. - Service Discovery is another concept. In real life you will use Kubernetes or Service Mesh which will internally do Service Registry and Discovery.
i created an android application that requires use of web service
i want it to be able to access the app everywhere therefore i need
my web services to be public with an external ip so i can access
what is the best way to do it?
I have an Amazon Web Services account i dont know if created an instance and run the web services there will be the best solution
My big problem with Amazon instance is that it takes a while to show in the app the result of the web service
Any ideas in how to make my web service public?
It appears that your requirement is:
Expose a public API endpoint for use by your Android application
Run some code when the API is called
There are two ways you could expose an API:
Use Amazon API Gateway, which that can publish, maintain, monitor, and secure APIs. It takes care of security and throttling. A DNS name is provided, which should be used for API calls. When a request is receive, API Gateway can pass the request to a web server or can trigger an AWS Lambda function to execute code without requiring a server.
Or, run an Amazon EC2 instance with your application. Assign an Elastic IP Address to the instance, which is a static IP address. Create an A record in Amazon Route 53 (or your own DNS server) that points a DNS name to that IP address.
I have a web app and a web service (which will be uploaded to Azure as an web app). How can i make my web service private (not accessible to the public, only accessible by the web app). Apparently you're able to do it with an App Service Environment but there isn't much documentation on it.
Is it possible?
You can follow this article to set it up: https://azure.microsoft.com/en-us/documentation/articles/app-service-web-how-to-create-an-app-service-environment/
The main difference between App Service and App Service Environment (ASE) is that App Services run on a pre-built, shared tenant hyper scaled web farm, but ASEs are purpose built (on demand) web farms provisioned directly in your subscription that must be attached to a VNET. Because you can attach your ASE to a VNET, you can then apply Network Security Groups (NSG) to the VNET to prevent/allow traffic to flow to the ASE.
Here is the page describing how to add the layered security to your ASE once you've built it:
Layered Security Architecture with App Service Environments
So with ASE you get the deployment/monitoring/management features of App Services, but with the network layer control of a VM.
How can i make my web service private (not accessible to the public, only accessible by the web app).
Network Security Groups could be used to control network traffic rules at the networking level, we could apply Network security group to the subnet to let Network security group act as a firewall in the cloud. #Russell Young has shared us a good article about setting up Network security group, you could read it. And you could check this blog that explained securing network access using Network Security Groups.
Besides, it is easy to implement a custom authentication to prevent unauthenticated client from accessing to your Web service at application layer. For example, we could use SOAP headers for authentication. Web service client credentials would be passed within the SOAP header of the SOAP message when the client want to access to Web service, and then Web service will validate SOAP header, if it contains the authentication credentials, the client will be authorized to access to the Web service.
You could check Implement Custom Authentication Using SOAP Headers.