[Apiman-user] Swagger + oauth2

[Eric Wittmann]

I think this is correct, Christina.  One of the advantages of apiman is 
to push some of the common API functionality like authentication into 
the apiman layer so that your API implementation don't have to worry 
about that.

So yes - you will be able to simply deploy a REST API into a vanilla 
wildfly application server, and then you can protect it by managing the 
authentication *only* in apiman.

-Eric

On 3/24/2015 12:55 PM, Christina Lau wrote:
> Hi Eric, if I understand you correctly, it is good. Let me validate what
> you say so far, with this new change, I can simply deploy my REST APIs
> into say a vanilla wildfly application server.
>
> Then I can either use my own APIKey policy, or use your newest OAuthKC
> policy, and then I have the support for an api that is either secured by
> APIKey or OAuth2 with roles.
>
> Is that correct? If yes, it is great because I have very complex topology
> as I have to have a version of the APIs that is vanilla (if I want to just
> secure by API key) and a version that has the keycloak metadata (json,
> web.xml etc) deployed into a keycloak server.
>
> Christina Lau
> mobile: 1-647-527-1145
>
>
>
>
>
> On 2015-03-24, 12:42 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> Hi Christina.
>>
>> Marc and I had a discussion today about OAuth security and I think we
>> agree on a few points.
>>
>> First of all, I think the typical approach to using apiman for
>> authentication is to enable Keycloak OAuth at the apiman layer, and then
>> to *NOT* enable Keycloak anywhere on your back-end service.  Typically
>> users would ensure that only apiman could invoke the back-end service,
>> either by doing something at the network layer (network security) or
>> some other mechanism.  Marc is looking into the options for securing the
>> connection between apiman and the back-end service (options include
>> certificate authentication and separate server->server oauth).  But the
>> idea is that the back-end service wouldn't know anything about Keycloak
>> - only apiman would.
>>
>> Here is a picture of how that might look:
>>
>> https://docs.google.com/drawings/d/1ggNcUuoMIU0zJDFBXVwPMGLovRpXWHoqlmXi2q
>> a5vHo/pub?w=1440&h=1080
>>
>> The client is responsible for getting the bearer token and including it
>> in the request to the managed service.  apiman would then consume the
>> bearer token and validate it, then strip it from the request.  apiman
>> would then proxy the request to the back-end service, using eithet
>> network trickery or something like certificate authentication to ensure
>> that only apiman can invoke it.
>>
>> The missing piece is then authorization.  So we are planning on creating
>> an Authorization policy (or perhaps we will augment the current keycloak
>> oauth policy impl) that will allow you to map resource regular
>> expressions to required role(s).  This would allow you to configure all
>> of your security (authentication + authorization) in apiman.  The only
>> thing you would use keycloak for is managing the users and the roles
>> that those users have.
>>
>> So it would look like this:
>>
>> https://docs.google.com/drawings/d/1b9ceXyOA3wzxtrav4UHERnaXE9o40D2lCUW6wF
>> QHxBA/pub?w=960&h=720
>>
>> What do you think about this approach?  I think it's the right way to
>> go, but we're obviously open to suggestions.  If you agree, then I think
>> our to-do list is:
>>
>> 1) Add authorization capabilities either via a new policy or as part of
>> the existing OAuth policy
>>
>> 2) Figure out the best way to secure the connection between apiman and
>> the back-end service (perhaps certificate auth)
>>
>> For some users #2 will be optional, with the assumption that they will
>> configure their network to ensure that external clients cannot directly
>> access back-end services.
>>
>> -Eric
>>
>