[Apiman-user] Authorization question

[Marc Savy]

Hi Stephen,

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

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.

Some policies could definitely use some feature expansion and general
(re)polishing; this will be a focus in the near future.

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.

Regards,
Marc

On Tuesday, November 14, 2017, Stephen Henrie <stephen at saasindustries.com>
wrote:

> Hi Marc,
>
> 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.
>
> 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.
>
> Thanks for checking in though.
>
> Stephen
>
> On Mon, Nov 13, 2017 at 12:37 PM, Marc Savy <marc.savy at redhat.com> wrote:
>
>> Hey Stephen,
>>
>> Any progress on this? Did you manage to solve your issue?
>>
>> Regards,
>> Marc
>>
>> On 10 August 2017 at 10:33, Marc Savy <marc.savy at redhat.com> wrote:
>> > Is your setup roughly:
>> >
>> > ClientApp -> Plan [Keycloak] -> API [Authz]
>> >
>> > Which version of Keycloak are you using?
>> > What type of roles are you using? For example, realm.
>> >
>> > The way Keycloak roles are modelled has changed fairly significantly
>> > over the last few versions of KC. We might not be handling that
>> > correctly anymore.
>> >
>> > On 8 August 2017 at 11:08, Marc Savy <marc.savy at redhat.com> wrote:
>> >> Hi,
>> >>
>> >> If I understand your description correctly, this should work. And in
>> >> my quick tests, it seems to work.  I might not be replicating
>> >> your setup perfectly though.
>> >>
>> >> For example let's imagine we have a setup such that:
>> >>
>> >> Client Policies [] // None
>> >> Plan Policies [Foo, Bar]
>> >> API Policies [Baz]
>> >>
>> >> This ultimately flattens to a policy chain of:
>> >>
>> >> Caller <-> [ Foo <-> Bar <-> Baz ] <-> API
>> >>
>> >> So if your setup is (N of):
>> >>
>> >> Plan [ Keycloak Auth ]
>> >> API [ Authz ]
>> >>
>> >> This should always result in: Keycloak *then* Authz, passing roles as
>> >> defined in config.
>> >>
>> >> If that isn't happening then there's a bug. I may may need to collect
>> >> some more information from you to see whether I can replicate the
>> >> issue.
>> >>
>> >> Regards,
>> >> Marc
>> >>
>> >> On 5 August 2017 at 01:21, Stephen Henrie <stephen at saasindustries.com>
>> wrote:
>> >>>
>> >>> My goal is minimize the amount of Apiman configuration that I need to
>> do by
>> >>> sharing a single, common authentication Plan using the Keycloak plugin
>> >>> across all APIs while using an API specific authorization policy for
>> each
>> >>> individual API.
>> >>>
>> >>> As such,  I am trying to configure a single, global plan within
>> Apiman that
>> >>> can be used for ensuring authentication policy using the Keycloak
>> plugin
>> >>> which forwards all of my realm roles. This single plan would be
>> assigned to
>> >>> all of my APIs in the Org, which would allow me to only have to
>> configure
>> >>> the Keycloak realm information in one place. Then for each individual
>> API, I
>> >>> was hoping to add a single Authorization policy plugin configured with
>> >>> endpoints and paths specific for each API.
>> >>>
>> >>> Something like
>> >>>
>> >>> Api1 ---> Keycloak Plan Abc
>> >>>   +---->Authorization Policy (123)
>> >>>
>> >>> Api2 ---> Keycloak Plan Abc
>> >>>   +---->Authorization Policy (456)
>> >>>
>> >>>
>> >>> When I do this and call one of the API endpoints, I am getting the
>> following
>> >>> error:
>> >>>
>> >>> curl -k  -H "Authorization: Bearer $T"
>> >>> https://localhost:9443/apiman-gateway/chassi/chassi-tenant-b
>> ff/1.0/mytenants
>> >>>
>> >>> {"type":"Other","failureCode":10010,"responseCode":0,"message":"No
>> roles
>> >>> have been extracted during authentication.  Make sure the
>> authorization
>> >>> policy comes *after* a compatible authentication policy in your
>> >>> configuration.","headers":[]}
>> >>>
>> >>> It would seem that the Keycloak plugin that is configured in the Plan
>> >>> assigned to the API is not forwarding the realm roles to the
>> Authentication
>> >>> policy which is also assigned to the same API.
>> >>>
>> >>> Is this by design? Do the authentication and authorization policies
>> have to
>> >>> be within the same entity (ie. Plan, Api, etc) and not passed out of
>> a plan
>> >>> to be used by downstream policies?  If so, is there another way to
>> configure
>> >>> plans and policies that will allow me to accomplish my goal?
>> >>>
>> >>> Thanks in advance!
>> >>> Stephen
>> >>>
>> >>> _______________________________________________
>> >>> Apiman-user mailing list
>> >>> Apiman-user at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20171114/f9605adf/attachment-0001.html