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/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 >