I have a REST API developed using Mule. It is deployed on prem Test and SystemTest environments. I can see that using Postman we can hit both test, systemtest API.
How do I make sure only applications can consume the API in the appropriate environments. There are system userids for each environments(C-users) and passwords which can be given to application consumers. The credentials need to be validated with Active directory LDAP Server.
How can we achieve this via Mule ESB?
For ex: application a1 running in Test should be able to consume only the API running in TEST. Application a1 running in Test should be able to consume only the API running in TEST.
Vinay,
I assume that the option of having multiple environments is not achievable.
Do you have access to Anypoint Platform? If you do, you can register your API there and generate a client id per environment.
Then you can apply Client ID Enforcement policy.
Related
I have multiple API's which I have exposed it via Azure API Management.
I am using one instance for across various environments. So currently I am adding / updating the API's / operations manually. Also I am setting cache, rewrite url for few of these operations. But now managing these are becoming a bit of too much work.
Is there a way, when any operation contracts changes in an API, I can then build / refresh the APIM and also setup the cache, re-write url, policies etc without manual intervention in APIM?
You can consider use Swagger, the OPEN API in Azure to control the data flow with Azure API policy for security and using Azure provided REST API to provision the APIm service and use the App Service to build the backend.
General Concept Flow
AGW <> APIM <> API <> App Service
enter image description here
Do they each have a specific purpose? Is one better suited than the other for a particular task?
They are two different distributions and serve different purposes.
API Gateway- It has specific features to communicate to Anypoint Platform to manage APIs, apply runtime policies, send analytics, track APIs.
Task- For deploying your proxy API Application
Mule Server- Mule server is the runtime you use for your integrations.
Task- For deploying your actual implementation API Application
Since Mule runtime version v3.8.0, both are one and the same. This means that since that version, the runtime is shipped with API Gateway capabilities, and there is no more API Gateway specific distributions released. To enable API Gateway capabilities, if you have the correct entitlement, you only need to specify your organization credentials or environment credentials (this last, it is only applicable to Mule 4 or newer).
API Gateway capabilities are the only ones who "know" how to apply/un-apply Anypoint Policies and generate Analytics info, among other things.
For runtimes released before v3.8.0, the only way to leverage those capabilities was to use API Gateway distribution. For example, API Gateway v2.x is based on Mule runtime v3.7.x.
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
Do i have the options of continuous deployment in wso2 api manager. For example - I have configured an API in test region & once API testing is done i need to promote the API to UAT region automatically rather than login again in UAT region configure the same API.
Currently we don't have that support. We have this feature in our roadmap.
You can do it by programmatically. write a java client to get the api details from one environment and then publish to the target environment using apimanager's publisher apis[1].
https://docs.wso2.com/display/AM170/Publisher+APIs
The company I'm working at does not have a great Infrastructure, it is treated as one big network, there is no network segregation. As such when were developing applications we have a TEST/UAT/PROD/DR setup. I have been developing a suite of services that have been deployed on all the above regions. How do i make sure that a developer can not call a production web service by accident? Is there anyway to restrict the service by caller (ie: server name?).
BTW all these services are internal and are not externally available.
Thanks Again for your help.
Josh
You could use Role based Authorization
Authorization In WCF-Based Services