Hi Scott.
Let me make sure I understand the requirement. You have two paths to
your API:
1) "public" endpoint that anyone can use, but requires authentication
via OAuth (and has other policies enforced)
2) "b2b" endpoint only usable by specific clients via an API Key and no
OAuth required
If this is correct, then you might consider another option, which is to
have two APIs pointed to the same back-end API. So if you are managing
an "Inventory" API (for example) you could manage it twice in apiman:
* Public Inventory API
* B2B Inventory API
And then you can configure the Public one with a bunch of policies,
including OAuth. It would have a public apiman endpoint *without* any
sort of API key.
Conversely, the B2B API could be configured with one or more plans, and
would require Client Apps (and thus API Keys) to be created for each
server connecting to it.
The major downside to this approach is that it would split your metrics
data across the two APIs.
---
One thing to mention about API Keys in apiman - they aren't really
*secure* out of the box. Whenever a Client App is created, an API key
is generated - but by default it's just a java UUID. For additional
security, you could generate your own keys in a couple of ways. Just
something to keep in mind (perhaps a future discussion if necessary).
-Eric
On 4/25/2016 5:31 PM, Scott Dunbar wrote:
Hello,
I'm evaluating apiman for a use case and am trying to get my head around
a requirement that I have and how that fits in with apiman.
I have normal username/password users that I can use the Keycloak OAuth
token system for and that works fine. I'm interested in using some sort
of api key for server to server communication. Ultimately a customer
wants to encode a single key and not get an OAuth token that expires.
If I understand the way that the client API's work I believe that I can
implement this through there but I want to make sure I'm understanding
correctly.
I think that I would implement two plans. The "public" plan would
include the policies that I want (Oauth and role based authorization)
and use Oauth. Then I would create a client API for the
server-to-server communication and that would use a different plan that,
assuming that the api key was correct, would not have any other
policies. Obviously that means that the key is very private.
Am I thinking of this the right way? The advantage of the client API
path is that I could shut down a "server" (i.e. the server of a customer
interacting with our server) in one shot by unregistering the client.
The APIMAN-282 method would work too in that I could create a single
user for the customer and lock that account if I wanted to block
access. Of course, the APIMAN-282 enhancement is still in progress and
I'm not sure it will see the light of day.
So the short question is is the two pronged approach the way to go
without an APIMAN-282 type of policy?
Thanks for your help.
--
Scott Dunbar
Cell: 303 667 6343
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user