[Apiman-user] Swagger + oauth2

Eric Wittmann eric.wittmann at redhat.com
Tue Mar 24 14:04:06 EDT 2015


Will do.  We're currently closing in on finishing up the conversion of 
the UI from GWT to angular.  Target release for 1.1.0.Final is end of 
next week.  After that we'll quickly get to work on all this non-UI 
related stuff for a 1.1.1.Final, perhaps a week or so later.

-Eric

On 3/24/2015 1:55 PM, Christina Lau wrote:
> Ok great, let me know when you have something that I can try.
>
> Christina Lau
> mobile: 1-647-527-1145
>
>
>
>
>
> On 2015-03-24, 1:50 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> 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/1ggNcUuoMIU0zJDFBXVwPMGLovRpXWHoqlmXi
>>>> 2q
>>>> 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/1b9ceXyOA3wzxtrav4UHERnaXE9o40D2lCUW6
>>>> wF
>>>> 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
>>>>
>>>
>


More information about the Apiman-user mailing list