In plenty of enterprises, networks are either locked down or have very limited access to the Internet; often for security, privacy or other practical reasons.
We’ve carefully designed apiman to be fully featured and easily configured when no Internet access is available; providing a great deal of flexibility and eschewing any "off-site only" functionality.
So, if you’re looking for API management in a locked-down network or Internet-free environment, read on!
Apiman’s extensibility is one of its key strengths, and it’s extremely easy to write plugins that can do almost anything. There are two default behaviours we are likely to want to configure when operating within a restricted network.
Apiman plugins are, by default loaded via The Central Repository (often known as Maven Central), which is a fantastically convenient in most situations. All of apiman’s components (manager, gateways, etc), will pull down the necessary plugins as and when they need them.
However, without Internet access this clearly won’t work as intended. We have three good options which you can configure in
apiman.plugins.repositories=https://repo1.example.local/our-internal-repo/,http://repository.example.org/nexus/content/groups/public/ (1) apiman.plugins.repositories=file:///mnt/nfs/my/shared/maven/repo (2) apiman.plugins.repositories=(3)
|1||Use an internal repository or mirror to deploy your own (and community) plugins to. This is likely the best option for many enterprises who may already have such infrastructure. Join multiple repositories with commas.|
|2||Mount a repository to a shared volume or filesystem on every machine running apiman.|
|3||Copy a valid Maven formatted repository containing your plugins to |
Advanced: You can replace the default registry entirely with an implementation of your own and set it via |
Our community releases contain a plugin registry which downloads a curated list of plugins. This lets the API Manager have a nice pre-populated list of plugins to install, rather than having to type the coordinates manually. To preserve this functionality simply download the registry file and make it available internally:
apiman-manager.plugins.registries=https://rawgit.com/apiman/apiman-plugin-registry/master/registry.json (1) apiman-manager.plugins.registries=file:///path/to/my/registry.json (2)
|1||The default JSON plugin registry’s data URL.|
|2||As <1>, but replaced with a local copy. Naturally, you may want to add your own plugins here in place of the curated ones. A custom registry may not even use JSON - it’s entirely up to you.|
When running in WildFly/EAP you can use appropriate platform system properties to make the config more portable: |
The demonstration API Catalogue (or catalog, if you’re into American English) is also downloaded from the Internet, so you may want to make it available offline and customise it, too.
Albeit not the topic of this blog, it’s worth briefly mentioning most advanced users will likely want to implement code  to search a real registry or catalogue for APIs to import, such as Kubernetes' service registry.
apiman-manager.api-catalog.catalog-url=https://rawgit.com/apiman/apiman-api-catalog/master/catalog.json (1) apiman-manager.api-catalog.type=io.apiman.manager.api.core.catalog.JsonApiCatalog (2)
|1||Default API catalogue. You can replace it with |
|2||If you write your own catalogue, then provide your own catalogue’s implementation of the |
Some API managers have off-site only metrics implementations. Rest assured, there’s none of that nonsense here! Just ensure that your metrics store (such as ElasticSearch) is available for apiman to connect to, and it’ll work fine.
A handful of trivial tweaks are potentially necessary to make all of apiman’s features work in a locked-down environment.