Blog Posts subscribe

Version 1.5 of Apiman is released!

Aug 13, 2018 Marc Savy apiman and release

I’m happy to announce that Apiman 1.5.1.Final is out.

It contains an important new policy feature: the ability to modify policy failures before they are returned to users (even if they are thrown by another policy).

This means that policies such as CORS can add their headers, irrespective of whether the request was successful or not (e.g. due to rate limiting).

Customising path patterns for your Apiman Gateway

Jul 3, 2018 Marc Savy apiman, gateway, manager, plugin, and extensibility

One common request we hear is how to create custom URL patterns for the Apiman Gateway.

For example, this means allowing changing the (Public API) default:

http://gatewayhost:port/{organizationId}/{apiId}/{version}/

To a custom alternative. As a simple example we’re going to hard-code an organisation in. We’ll assume that we’ve established a convention to always publish our APIs to a particular org. That will change the pattern to:

http://gatewayhost:port/{apiId}/{version}/
If you’re using the Vert.x Gateway you should use Apiman 1.4.3.Final or later as a bug prevented plugins from loading from static config.

Version 1.4.3 of Apiman is released!

Jul 3, 2018 Marc Savy apiman and release

Apiman 1.4.3.Final is out. It contains a couple of bug-fixes. Most notably, a bug in the Vert.x Gateway that prevented plugins specified in static config (conf.json) from being loaded properly.

Version 1.4 of Apiman is released!

Jun 22, 2018 Marc Savy apiman and release

I’m delighted to announce that Apiman 1.4 has been released (actually, 1.4.1.Final as of this blog post [1]).

The most important change in this release is that we’ve upgraded support for Elasticsearch from 1.x to 5.x. It may also support Elasticsearch 2.x, but this isn’t officially supported (let us know your experiences).


1. We fixed a couple of bugs spotted in 1.4.0.Final by the community before the blog was written

Version 1.3.5.Final of Apiman is released

Apr 28, 2018 Marc Savy apiman and release

Apiman 1.3.5.Final is out and ready for you all to try.

This just contains some UI reversions, as we still have some tough-to-fix gremlins. We’ll bring the updates back once we’re able to fix the issues.

It contains all of the same fixes and features as 1.3.4.Final.

Download 1.3.5.Final

Version 1.3.4.Final of Apiman is released!

Apr 27, 2018 Marc Savy apiman and release

Apiman 1.3.4.Final is out and ready for you all to try.

You may be wondering where 1.3.2.Final and 1.3.3.Final are; early community testing found some regressions, so we skipped formally announcing those.

Download 1.3.4.Final

Tonnes of bug-fixes

If you had bugs, please try 1.3.4.Final. There’s a reasonable chance we addressed them.

This includes issues such as: same-key headers being handled improperly in the Servlet edition; a variety of config and UI bugs; import-export issues; Vert.x config and connection issues.

If you still have problems, then please let us know on the mailing list or via filing a bug.

List entities directly on the Gateway API

We extended the Apiman Gateway API to allow you to list entities directly. This is useful for our CLI (which will soon be bundled with Apiman releases).

We’ll have some more formal documentation shortly, but a short summary:

The credentials to access the Apiman Gateway API are likely different than the UI. The quickstart demo is apimanager/apiman123!.

Example:

$ curl -k 'https://apimanager:apiman123!@localhost:8443/apiman-gateway-api/organizations'

["FooOrganization", "OtherOrg"]
List Organizations

apiman-gateway-api/organizations

Returns: Array of Organization IDs.

List all APIs in Organization

api-gateway-api/organization/{Organization ID}/apis

Returns: Array of API IDs.

List all Api Versions in Organization

api-gateway-api/organization/{Organization ID}/apis/{API Version}

Returns: Array of API Version objects.

List all Clients in Organization

api-gateway-api/organization/{organizationId}/clients

Returns: Array of Client IDs.

List all Client Versions in Organization

api-gateway-api/organization/{Organization ID}/clients/{Client Version}

Returns: Array of Client Version objects.

WildFly 11

We’re now officially distributing a WildFly 11 overlay, with a newer version of Keycloak.

There are corresponding Docker quickstart images available.

Master Docker builds

As a component of our CI, we are now producing Docker builds of all successful builds of Apiman’s master branch. So, if you need to test something on the bleeding edge, it should be much easier now.

docker run -it -p 8080:8080 -p 8443:8443 apiman/on-wildfly11:master

Latest always refers to the latest release (e.g 1.3.4.Final), whilst master refers to the latest successful HEAD of master and hence moves frequently.

CLI work

Working with the community, we’ve been successfully developing a large amount of CLI functionality. We expect this to be bundled with an Apiman release soon.

One key feature will be the ability to apply YAML declarations against the Apiman Manager or Apiman Gateway, allowing users to set the state of their system in a more static way.

This will be in addition to traditional CLI functions to do one thing at a time.

Separate blog-post on that soon.

Apiman plans to move to Elasticsearch 5.x. Give your feedback.

The next planned release of Apiman will move Elasticsearch to 5.x. We plan to drop ES 1.x support. If an upgrade/migration would be particularly problematic, please let us know on the mailing list or open a ticket.

The work on this is nearing completion, so feedback now would be valuable.

Release Notes

Note that some issues resolved may not have been assigned tickets, so this is a partial set.

Thanks to the Community

Thanks to the community for their valuable contributions to this release. We had a meaningful number of features, bug reports, and bug-fixes.

Version 1.3.1.Final of apiman is released!

Jun 29, 2017 Marc Savy apiman and release

I’m delighted to announce that Apiman 1.3.1.Final is out, with several notable new features and improvements [1].


1. The more eagle-eyed amongst you will no doubt have noticed that most of this was actually released a few days ago.

Version 1.3.0.Final of apiman is released!

May 25, 2017 Marc Savy apiman and release

Last week we released apiman 1.3.0.Final. It’s been rather a long while coming, but hopefully you’ll be pleased with the improvements.

This release has some important new features, a substantial number of bug-fixes, and marks the official release of the Apiman Vert.x Gateway.

Importantly, this release has a lot of background work which has prepared the the ground for the upcoming initial community integration with 3scale, as outlined in previous blogs.

Performance tuning the Apiman Gateway (WildFly, EAP, Tomcat)

May 15, 2017 Marc Savy apiman, gateway, and performance

In this blog, we’ll outline a few simple tweaks you can make to improve the performance of the Apiman Gateway when running on servlet platforms (WildFly, EAP, Tomcat, etc).

Most of the focus will be on WildFly and EAP, but others will be more broadly applicable.

Naturally, these are very rough pointers and should merely be hints for areas that could prove fruitful. There’s no one-size-fits all approach to tuning, so always profile and keep tweaking to find the best settings for your workloads.

3scale and apiman - Part Deux

Aug 19, 2016 Eric Wittmann apiman and 3scale

It’s been almost two months since Red Hat announced it was acquiring 3scale Technologies and turning the 3scale API Management solution into a Red Hat supported product. In that time, we’ve been trying to figure out some stuff for the apiman community. Here some of the things we wanted to suss out:

  • How the apiman development team can best focus its efforts, now that 3scale will be the basis for Red Hat’s API Management technology.
  • How to best support the existing apiman community going forward, given the restrictions on continued development of the apiman API Management solution.
  • How can existing apiman users transition to a Red Hat supported API Management solution.

It doesn’t sound like much, but it actually really is. We’ve made some preliminary decisions, and because we want to be as transparent and upfront as possible, read on to find out what they are!

Red Hat, 3scale, and apiman?

Jun 22, 2016 Eric Wittmann apiman and 3scale

As some of you have undoubtedly already heard, Red Hat recently announced the acquisition of 3scale, a commercial vendor of API Management software.

Because the apiman project is sponsored primarily by Red Hat, you may be wondering how this impacts the project and its open source community. In today’s blog post, I’ll do my best to answer that question as honestly and transparently as I can.

Version 1.2.4.Final of apiman is released!

Apr 24, 2016 Eric Wittmann apiman and release

Greetings, earthlings! On Friday of last week we released the absolute best version of apiman ever! This release has a fair number of bugs fixed, as well as a few new things. Read on for the details!

Covering Your Assets: Data Encryption in API Management

Apr 13, 2016 Rachel Yordán security and gateway

In a world where APIs are quickly becoming the standard, most of us understand the importance of following best practices for API security. We authenticate, authorize and throttle requests. We encrypt the data that we share with other applications (hopefully!). But we often neglect one of the most essential components of the API layer: data storage.

Using apiman in a network with limited Internet access

Apr 5, 2016 Marc Savy configuration, production, and offline

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 1.2 - Introduction to User Roles in apiman

Mar 28, 2016 Len DiMaggio apiman, introduction, overview, users, and roles

In this post, we’ll examine apiman user roles. In the apiman data model, all data elements exist in the context of the organization. The same holds true for user memberships as users can be members of multiple organizations. Permissions in apiman are role based. The actions that a user is able to perform are dependent on the roles to which the user is assigned when a user is added as a member of an organization.

Version 1.2.3.Final of apiman is released!

Mar 24, 2016 Eric Wittmann apiman and release

Greetings, earthlings! Yesterday we released the best version of apiman yet, and I’m not just saying that because the version number (1.2.3.Final) is awesome. This release has a bunch of bug fixes in it, as well as a few targeted new features. Read on for more details!

Import APIs Into Apiman (API Catalog)

Mar 23, 2016 Eric Wittmann apiman, 1.2.x, manager, and catalog

One of the less enjoyable aspects of apiman is the manual addition of an API that you wish to manage. And if you have a bunch of APIs you want to manage, you can either use the apiman REST interface to script the creation of them, or else you’re stuck manually entering them into the UI.

However, if you take advantage of the new API Catalog feature, things might get a lot easier!

Storing Your Gateway Config in a Database

Mar 9, 2016 Eric Wittmann apiman, 1.2.x, gateway, jdbc, and registry

One of the strongest features of apiman, in general, is its excellent extensibility. Not only is it easy to add new policies, for example, but many of its core components are also pluggable. This includes, for example, the registry used by the API Gateway to store configuration information published to it by the manager. This blog post will detail a new JDBC based implementation of that registry, explaining how you can store that information in a Database instead of in Elasticsearch (the default setting).

Re-Registering Your Client App(s)

Feb 24, 2016 Eric Wittmann apiman, 1.2.x, and gateway

In a recent blog post I explained why APIs used to be completely frozen once they were published, and how we have loosened that restriction for Public APIs. Similarly, we did not allow Client Apps to be changed and then re-registered. This was never a good decision, since the Client App does not have anything “connected” to it (the way that an API may). So we should never have restricted the registration of a Client App!

Re-Publishing Your API(s)

Feb 24, 2016 Eric Wittmann apiman, 1.2.x, and gateway

An early design decision we made in apiman was to not allow APIs to be re-published to the Gateway. The reasoning was that Client Apps may have established Contracts with the API, and thus have agreed to specific terms and conditions (whether implicit or explicit). Therefore, we shouldn’t allow the API provider to modify those terms and re-publish the API, as it may violate the agreement.

However, we later added the concept of a Public API, which allows any client to invoke it without first creating a Contract. It is clear that API providers should be able to re-publish a Public API (presumably after changing the API’s configuration).

Apiman 1.2 - Improvements to Plugin Management

Feb 22, 2016 Len DiMaggio apiman, introduction, overview, plugin, and management

Apiman is not only preconfigured with a rich set of policies that you can use, right out of the box, but, from its earliest releases, apiman has also included a mechanism that you can use to define your own custom policies through plugins. This article describes the improvements introduced in apiman release 1.2.x that enable you to better manage your custom policy plugins.

Apiman 1.2.1 Export and Import

Jan 27, 2016 Len DiMaggio apiman, introduction, overview, backup, export, and import

The Question you Dread

If you use a computer at home or at work, you’ll eventually find yourself in a situation where you lose some important data and, while you are trying to recover it, someone asks you a question that is simultaneously annoying and terrifying:

“Did you make a backup?”

Happily, the 1.2 release of apiman includes a new feature that enables you to export and import your apiman data and provides you with an easy means to create apiman data backups. In this post, we’ll take a look at the new export/import feature, and how you can use it for a variety of tasks to protect your data, make your life easier, and enable you to avoid annoying and terrifying questions.

Apiman Names Have Been Changed to Protect the Guilty

Jan 27, 2016 Eric Wittmann apiman and 1.2.x

Recently we released version 1.2 of apiman and part of that release includes an effort to rename some concepts to make them more clear (or to better align them with industry standard terminology). Read on below the fold to find out what changed!

Cover yourself up! Protecting your APIs with mutual auth

Jan 22, 2016 Marc Savy gateway, security, mutual-auth, ssl, mtls, and 1.2.x

The last thing you want after carefully setting up your system with apiman is for someone to be able to call around the gateway and hit your APIs directly. The typical solution for this is to lock down your network so that the only publicly accessible part is the apiman gateway, whilst APIs are hidden in the private part of the network, which apiman can access, but not someone in the outside world. However, in some situations fine-grained network controls may not be available, such as the cloud; or, you may wish to have an additional layer of security to be reassured that no funny business is going on (such as imposters).

The class of solutions to this problem generally falls under the banner of mutual authentication. One such mutual auth offering apiman supports is Mutually Authenticated TLS[1].


1. Also commonly referred to as MTLS, MSSL, 2WAY, client authenticated TLS/SSL, two-way SSL, amongst other names!

Keycloak and dagger: Securing your APIs with OAuth2

Jan 22, 2016 Marc Savy gateway, security, oauth2, keycloak, authentication, authorization, and 1.2.x

One great advantage of API Management is centralising auth concerns, thereby avoiding burdensome reimplementation issues and streamlining your security processes. The good news is that you can easily configure apiman to handle many common auth use-cases, such as OAuth2 with our popular Keycloak OAuth2 policy which I’ll outline in this blogpost.

CORS? Of Course!

Jan 22, 2016 Marc Savy security, plugin, policy, cors, and 1.2.x

If you’re looking to define CORS policies in your API Management layer, then we have an official plugin that should be perfect for the job.

For those unfamiliar with CORS, it’s a way of precisely defining who and how a remote origin may invoke an API’s resources. Generally, due to the same-origin policy, a web browser will only allow the invocation of resources that reside on the same origin as the requesting page. This mitigates a range of malicious script attacks by preventing interaction with remote resources.

However, if we want our resource to be callable by some (or all) other origins, then we need to define a CORS policy which let’s user agent know what’s allowed.

Finally! Apiman 1.2.1.Final is released!

Jan 22, 2016 Eric Wittmann apiman

It’s been ages since apiman had a new release! Well the reason for that is we’ve been pushing to get the first version of 1.2.x out the door. I’m here to tell you - that day has finally arrived.

We’re happy to announce apiman 1.2.1.Final. Our goal is now to go back to our previous, more frequent, release schedule.

The More You Know: apiman micro-services?

Nov 12, 2015 Eric Wittmann micro-services and development

Let’s spend a little bit of time learning more about one of the newer ways you can run apiman: as a set of micro-services.

Running apiman in this way has several advantages, including (but not limited to):

  • Fast startup time
  • Fully decoupled
  • Easily debuggable from an IDE
  • Quick to test different configurations
  • Independently scale (esp. via fabric8/openshift/kubernetes)

apiman Limiting Policies

Aug 17, 2015 Len DiMaggio policies

In this, the sixth article in the series on apiman, JBoss’ new API Management framework, we’ll examine how apiman enables you to govern access to managed APIs through the use of rate limiting policies.

The runtime core of apiman is the API Gateway and the policies that it applies to incoming requests to APIs. apiman is configured out of the box with a variety of policies that can be used to govern access to APIs managed by the API Gateway based on IP address, user authentication, and usage levels. From its first release, apiman has supported rate limiting policies, where the upper limit for use of an API could be governed by a policy. In its new 1.1.6 release, apiman has expanded this support to include quota based limiting policies.

apiman Policy and Endpoint Security

Aug 3, 2015 Len DiMaggio security

In this, the fifth article in the series on apiman, JBoss’ new API Management framework, we’ll examine how apiman enables you to provide security for your managed APIs at the policy level, and and at the endpoint level for its managed and unmanaged endpoints.

Plugins - Not Just For Policies Anymore

Jul 24, 2015 Eric Wittmann api-manager, api-gateway, plugins, development, and maven

As you may know, apiman has long supported custom policies provided by users. If you aren’t familiar with apiman plugins, you can find more about them by clicking here.

As of version 1.1.5.Final, plugins are now even more useful. You can provide custom implementations of various core apiman system components via plugins. This allows users to customize apiman easily, without any changes to the classpath and without rebuilding the core apiman application.

In this blog post I’ll explain how it works.

Manage Fuse APIs with apiman

Jul 7, 2015 Stefan Bunciak api, management, jboss, and fuse

This article aims to provide a short guide on how to get API Management capabilities provided by apiman to work with JBoss Fuse, a lightweight, flexible, integration platform that is based on Apache Camel, an implementation of many of the most commonly used enterprise integration patterns (EIP).

At long last, Metrics R Us!

Jul 6, 2015 Eric Wittmann api-manager, api, ui, and metrics

A core feature of any good API Management solution is the recording of and reporting on interesting metrics related to API requests. Because apiman acts as a central Gateway for all managed API traffic, it is the perfect location to record information about each and every request. This allows it to report on interesting data it has recorded, related to response times, successful vs. failed requests, total number of requests broken down by time, consumer id, or plan used. As you can imagine, this is extremely valuable information and it is a bit embarrassing that we haven’t offered this functionality until now!

But that gap is finally filled with version 1.1.4.Final.

Microservices Architecture Day Appearance

Jun 15, 2015 Marc Savy microservices, conference, and talk

I had the pleasure of presenting on apiman at the recent Microservices Architecture Developer Day, with our colleague Kurt delivering a short demo of our software running within Fabric8. It was particularly enjoyable meeting developers who are interested in, or are already using, apiman - so, thank you for your insightful questions both during, and after, the presentation.

Given the packed schedule, there was a limited amount of time to explore apiman plus microservices, and hence this seems like a good opportunity to write a blog post expanding upon the themes I touched upon.

So, if you’re interested in understanding the value API management can have in a microservices architecture; please, read on!

Services, services, everywhere!

A microservices architecture encourages the decomposition of problems into small, isolated and reusable chunks; much in the same spirit as UNIX’s do one job and do it well philosophy. This brings with it a whole raft of benefits, for instance: we can scale each component independently, avoiding unnecessarily dragging along other components which just happen to reside in the same monolith; we can easily have a single team wholly responsible for a single microservice’s lifecycle, simplifying debugging and allowing them to use their skills and technologies of choice; and, we can easily create new functionality via composition. However, this proliferation of heterogeneous services poses some challenges, a significant subset of which API Management is a key solution to.

Avoiding reimplementation of cross-cutting functionality

A problem that can quickly become apparent is that key pieces of important common functionality are required that are difficult or undesirable to reimplement in every API. Good examples of this would be security concerns like authentication and authorization, or business concerns like rate-limiting, billing and auditing [1].

It’s quite clear why we would want to avoid this situation. Imagine we have hundreds of microservices we need to expose to the outside world; the nightmare scenario is that we have to implement complex and prone-to-change authentication and authorization schemes on each of them. Quite aside from bloating and complicating our microservices, it is going to be extremely difficult to guarantee that each service has implemented all of this common functionality consistently and correctly - we could quite plausibly be leaving holes in our system simply by virtue of surface area.

Instead, we can drastically improve the situation by using apiman to relieve individual services of that burden; simply configure and manage those tasks in a single, well-known location. We register our APIs with apiman, apply appropriate policies, and route public traffic through the gateway. We leave apiman to deal with these common problems, and let the microservice’s developers focus on their core task, rather than burning time on ancillary concerns.

Fickle business requirements

Access to APIs often has business requirements which are independent of the core functionality the service itself offers. For instance, whilst a mapping application might only be interested in coordinates, its business requirements could dictate that we need to capture metrics; initiate contracts with, and issue keys to, API consumers; and, audit their interactions with the system. Quite aside from the microservices faux pas of contaminating a service with external business logic, we generally want to avoid this situation, as business requirements tend to change rapidly in response to events which are unrelated to the service’s purpose.

For instance, marketing decide that the service is so popular that they’re going to offer two levels of access a gold plan and a silver plan; one of which allows 1000 requests per minute, the other 500. The developers trudge off and implement this in their service. Six months later, they decide they want to change this to bandwidth limits, and the silver plan should be able to do only GET requests. The developers of a variety of services are taken off their existing tasks to implement these changes.

Shifting business requirements are a natural part the software industry, however, the implementation burden is amplified in a microservices architecture. Thankfully, we can delegate that workload to our API Management solution, and even better, with the apiman UI it’s possible for non-technical people to create and manage the entire process. This is excellent from both standpoints, as the developers can concentrate on their core tasks, and the business people can take direct ownership and responsibility for implementing their policies; the two domains are kept entirely separate.

Naturally, there will be cases where the in-built policies don’t meet your specific needs. Apiman was designed grounds-up with the assumption that many users would want to write custom policies, and as such, we’ve written a number of guides on the topic. It’s extremely easy to create, install and version control your own policies, including UI components that make it trivially easy for non-technical people to drive.

Clear demarcation

Of all the microservices constituting an entire system, it is likely that only a subset of those should be exposed to the outside world. The rest are there to provide internal or compositional functionality. The apiman gateway can provide a natural boundary between public and private; only those services that are explicitly being offered through the gateway are visible, and the rest can be walled off (either at the network level, or via mutual authentication mechanisms).

Watching the world go by

If we want to determine the value of a service to our organisation, then we need some objective metrics to determine how it is being used and whether it is performing as well as we hoped. Ideally, metrics should be collected in a manner that is consistent amongst all services to ensure that comparisons can be made fairly. The apiman gateway is in a unique position to collect lots of interesting data; siting at the transit point between the outside world and the services being offered. We collect, amongst other things, timing information; round-trip latencies; detailed error information (error codes, error output); application, service and organisation IDs. These can be analysed to produce a rich set of information which you can use to characterise the behaviour (or misbehaviour) of your services, including how external applications are interacting with them.

Metrics collection, analysis and visualisation is an area we’re actively working hard on: in the community we’re looking to provide interesting opportunities to tie in with popular open source data-sinks and visualisers, whilst in integrated environments, we look to play well with native metrics collection infrastructure.

Papers, please

You may have lots of services to offer, but unless people can find them, they won’t know about how useful they are. Hence, it’s important to have a well-known service registry through which internal and external consumers can find and consume your APIs. Developers can easily log into the apiman UI to browse and search for registered APIs, and we also make it easy to integrate into any other registry, such as Fabric8’s.

In conclusion

API Management will be at the heart of many successful microservices setups. It unifies common functionality; provides a place to discover, register and manage services; reduces the scope for costly errors and inconsistencies; and, provides a natural barrier between internal and external where it can collect valuable metrics and audit information.

It was a pleasure to meet all of those developers who are interested in apiman - and it was particularly interesting to hear your use-cases. I would encourage you to keep giving us your feedback, as it directly impacts our features, priorities and schedule.


1. See our user guide and be sure to look at our range of official plugin policies

Adding a BASIC Authentication Policy to a Managed API in JBoss apiman

Jun 11, 2015 Len DiMaggio authentication and policy

apiman logo

In this, the fourth article in the series on apiman, JBoss’ new API Management framework, we’ll examine how apiman enables you to not just manage APIs, but implement a layer of security to the APIs by adding an authentication requirement when client apps access a managed API.

Setting up your apiman development environment

Jun 4, 2015 Eric Wittmann eclipse, development, and maven

For those of you who might be interested in hacking away at some core apiman code, I thought it might be nice to create a reasonably comprehensive step-by-step guide. For the most part everything is straightforward, but there are a copule of tricks you can use to get up and running fast and to be able to easily iterate on any changes you make.

Read on if this sounds like something you want to do!

We got the moves like swagger!

Jun 2, 2015 Eric Wittmann api-manager, swagger, api, and ui

One of the weaknesses we’ve had in apiman until now is that API providers didn’t have any way to document how to consume their APIs. Well that has all changed with version 1.1.3.Final. Now you can upload a Swagger spec document for your API. If you do, consumers will be able to browse your API documentation directly in the apiman UI.

I think we can all agree that this is a welcome change and really improves the usability of the system, particularly from the perspective of the client app developer (aka the API consumer).

The JBoss apiman API Manager REST API

May 19, 2015 Len DiMaggio rest, api, and automation

In this, the third article in our series on apiman, JBoss’ new open source API Management framework, we’ll examine apiman’s API Manager REST API. apiman’s Management UI utilizes this API in the implementation for all of its user-visible features, and you can also use the same API to automate tasks with apiman.

Authorization: good god, what is it good for?

May 8, 2015 Eric Wittmann authorization, authentication, and policy

Quite a bit, actually. :)

I want to talk about how Authorization currently works in apiman, because it’s a little bit more loosely coupled than you might expect. Note that at some point in the future we’re going to be renovating how policies are defined and configured in the API Manager UI. But until then, you can refer to this blog post for an overview of how to configure Authorization!

Customizing JBoss apiman Through Policy Plugins

Mar 6, 2015 Len DiMaggio plugins, policies, development, and maven

This is the second in a series of articles exploring API management with JBoss apiman. The first article was a general introduction to apiman for impatient users where in only 10 minutes we installed apiman, created users and organizations, and APIs, policies, contracts, and client apps. In this article, we’ll take the first step toward customizing apiman by creating new plugins to implement API policies.

An Impatient New User's Introduction to API Management with JBoss apiman 1.0

Jan 9, 2015 Len DiMaggio introduction and overview

Software application development models are evolutionary things. New technologies are always being created and require new approaches. It’s frequently the case today, that a service oriented architecture (SOA) model is used and that the end product is a software service that can be used by applications. The explosion in growth of mobile devices has only accelerated this trend. Every new mobile phone sold is another platform onto which applications are deployed. These applications are often built from services provided from multiple sources. The applications often consume these services through their APIs.

OK, that’s all interesting, but why does this matter?