Re: [Apiman-user] Swagger + oauth2

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&gt; 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&gt; >> 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 >>> >>