Re: [Apiman-user] Swagger + oauth2
by Eric Wittmann
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(a)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(a)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
>>>>
>>>
>
9 years, 8 months
Re: [Apiman-user] Swagger + oauth2
by 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(a)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
>>
>
9 years, 8 months
Re: [Apiman-user] Swagger + oauth2
by Eric Wittmann
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/1ggNcUuoMIU0zJDFBXVwPMGLovRpXWHoqlmXi2...
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/1b9ceXyOA3wzxtrav4UHERnaXE9o40D2lCUW6w...
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
9 years, 8 months
Using a header for versioning
by Michael Chester
Hi,
Currently APIman inserts the version into the URL. We would like to use a
header instead. Is it possible to support this?
Regards,
Michael Chester
9 years, 8 months
