[Apiman-user] Client secret key and/or APIMAN-282

[Eric Wittmann]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>