<div dir="ltr">Hi Stephen,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Instead of requiring all of that preconfiguration data for each API to point the plugin to a specific keycloak realm, it dynamically makes a call to Keycloak in real-time to get and cache the token's realm's public key so that the oauth token can be validated.<br></blockquote><div><br></div><div>Thanks for describing this. When we created the KC policy this functionality wasn't yet available on their side. I think it would be a fantastic addition to the community plugin, so I've pencilled it in.</div><div><br></div><div>Some policies could definitely use some feature expansion and general (re)polishing; this will be a focus in the near future.</div><div><br></div><div>I suspect the CLI tooling and/or generated headless functionality might interest you, also? I'll be sure to solicit your feedback once that goes live.<br></div><div><br></div><div>Regards,</div><div>Marc</div><div><br></div><div>On Tuesday, November 14, 2017, Stephen Henrie <<a href="mailto:stephen@saasindustries.com" target="_blank">stephen@saasindustries.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Hi Marc,<br><br></div>Yes and no. We decided to go a different route and not use the contracts and plans, since we don't want to have to dole out apikeys. We are just using the "public" API functionality at this point. <br><br>However, in order to minimize the configuration needed for each new API entry, I went ahead and created a custom policy plugin which combines some parts of the keycloak oauth plugin and the authorization plugin. Instead of requiring all of that preconfiguration data for each API to point the plugin to a specific keycloak realm, it dynamically makes a call to Keycloak in real-time to get and cache the token's realm's public key so that the oauth token can be validated.<br><br></div>Thanks for checking in though.<br><br></div>Stephen <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 13, 2017 at 12:37 PM, Marc Savy <span dir="ltr"><<a>marc.savy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Stephen,<br>
<br>
Any progress on this? Did you manage to solve your issue?<br>
<br>
Regards,<br>
Marc<br>
<br>
On 10 August 2017 at 10:33, Marc Savy <<a>marc.savy@redhat.com</a>> wrote:<br>
> Is your setup roughly:<br>
><br>
> ClientApp -> Plan [Keycloak] -> API [Authz]<br>
><br>
> Which version of Keycloak are you using?<br>
> What type of roles are you using? For example, realm.<br>
><br>
> The way Keycloak roles are modelled has changed fairly significantly<br>
> over the last few versions of KC. We might not be handling that<br>
> correctly anymore.<br>
><br>
> On 8 August 2017 at 11:08, Marc Savy <<a>marc.savy@redhat.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>> If I understand your description correctly, this should work. And in<br>
>> my quick tests, it seems to work. I might not be replicating<br>
>> your setup perfectly though.<br>
>><br>
>> For example let's imagine we have a setup such that:<br>
>><br>
>> Client Policies [] // None<br>
>> Plan Policies [Foo, Bar]<br>
>> API Policies [Baz]<br>
>><br>
>> This ultimately flattens to a policy chain of:<br>
>><br>
>> Caller <-> [ Foo <-> Bar <-> Baz ] <-> API<br>
>><br>
>> So if your setup is (N of):<br>
>><br>
>> Plan [ Keycloak Auth ]<br>
>> API [ Authz ]<br>
>><br>
>> This should always result in: Keycloak *then* Authz, passing roles as<br>
>> defined in config.<br>
>><br>
>> If that isn't happening then there's a bug. I may may need to collect<br>
>> some more information from you to see whether I can replicate the<br>
>> issue.<br>
>><br>
>> Regards,<br>
>> Marc<br>
>><br>
>> On 5 August 2017 at 01:21, Stephen Henrie <<a>stephen@saasindustries.com</a>> wrote:<br>
>>><br>
>>> My goal is minimize the amount of Apiman configuration that I need to do by<br>
>>> sharing a single, common authentication Plan using the Keycloak plugin<br>
>>> across all APIs while using an API specific authorization policy for each<br>
>>> individual API.<br>
>>><br>
>>> As such, I am trying to configure a single, global plan within Apiman that<br>
>>> can be used for ensuring authentication policy using the Keycloak plugin<br>
>>> which forwards all of my realm roles. This single plan would be assigned to<br>
>>> all of my APIs in the Org, which would allow me to only have to configure<br>
>>> the Keycloak realm information in one place. Then for each individual API, I<br>
>>> was hoping to add a single Authorization policy plugin configured with<br>
>>> endpoints and paths specific for each API.<br>
>>><br>
>>> Something like<br>
>>><br>
>>> Api1 ---> Keycloak Plan Abc<br>
>>> +---->Authorization Policy (123)<br>
>>><br>
>>> Api2 ---> Keycloak Plan Abc<br>
>>> +---->Authorization Policy (456)<br>
>>><br>
>>><br>
>>> When I do this and call one of the API endpoints, I am getting the following<br>
>>> error:<br>
>>><br>
>>> curl -k -H "Authorization: Bearer $T"<br>
>>> <a href="https://localhost:9443/apiman-gateway/chassi/chassi-tenant-bff/1.0/mytenants" rel="noreferrer" target="_blank">https://localhost:9443/apiman-<wbr>gateway/chassi/chassi-tenant-b<wbr>ff/1.0/mytenants</a><br>
>>><br>
>>> {"type":"Other","failureCode":<wbr>10010,"responseCode":0,"messag<wbr>e":"No roles<br>
>>> have been extracted during authentication. Make sure the authorization<br>
>>> policy comes *after* a compatible authentication policy in your<br>
>>> configuration.","headers":[]}<br>
>>><br>
>>> It would seem that the Keycloak plugin that is configured in the Plan<br>
>>> assigned to the API is not forwarding the realm roles to the Authentication<br>
>>> policy which is also assigned to the same API.<br>
>>><br>
>>> Is this by design? Do the authentication and authorization policies have to<br>
>>> be within the same entity (ie. Plan, Api, etc) and not passed out of a plan<br>
>>> to be used by downstream policies? If so, is there another way to configure<br>
>>> plans and policies that will allow me to accomplish my goal?<br>
>>><br>
>>> Thanks in advance!<br>
>>> Stephen<br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> Apiman-user mailing list<br>
>>> <a>Apiman-user@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/apiman-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/apiman-user</a><br>
>>><br>
</blockquote></div><br></div>
</blockquote></div>
</div>