Funny you should suggest that - the plugins will be *much* easier to
install in version 1.2.x because there is a UI which lists all the
available "official" apiman plugins. Of course you can also still
install your own plugin via the UI.
I'm also toying around with the idea of pre-installing some of the
plugins so they are automatically included in the apiman quickstart.
-Eric
On 10/10/2015 5:39 AM, Tim Dudgeon wrote:
Yes, indeed I was looking at the wrong policy.
The Keycloak OAuth Policy looks exactly what I need and the blog post
describes it well.
You should make those non-bundled policies more visible!
Tim
On 09/10/2015 19:11, Eric Wittmann wrote:
> Perhaps you are looking at the wrong policy. The one you want to use
> is the Keycloak OAuth Policy, which is available if you install the
> appropriate keycloak plugin. A blog post about it can be found here:
>
>
http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication...
>
>
> The Authorization policy only does role-based access control, not
> OAuth authentication. The Keycloak OAuth policy should be configured
> first, and then the roles found in the bearer token will get passed to
> the Authorization policy, which should be configured 2nd.
>
> -Eric
>
> On 10/9/2015 2:01 PM, Tim Dudgeon wrote:
>> Yes, but I don't see how a different realm/server this can be configured
>> with the current Authorization policy.
>> Is this possible?
>>
>> Tim
>>
>> On 09/10/2015 18:56, Eric Wittmann wrote:
>>> I would argue that using some *other* realm (NOT the apiman realm) is
>>> the more sensible thing to do.
>>>
>>> In fact, I might go so far as to suggest a second keycloak server
>>> would make more logical sense than using the apiman one. Of course,
>>> practically speaking it makes sense to just have one KC server. But
>>> definitely I think you want to create other realms - and one realm per
>>> organization is a very sensible approach.
>>>
>>> -Eric
>>>
>>> On 10/9/2015 1:10 PM, Tim Dudgeon wrote:
>>>> Picking up on this again, you mentioned OAuth2 authentication.
>>>> By this I'm assuming you mean what's listed as
"Authorization
>>>> policy" in
>>>> the available policies, and this authenticates against the apiman
>>>> realm
>>>> in keycloak.
>>>>
>>>> Is it possible/desirable to allow a different realm to be configured
>>>> here? The idea being that an organisation could create a policy that
>>>> authenticates against a realm configured for that organisation (maybe
>>>> using its own LDAP server etc.). This way an organisation can
>>>> configure
>>>> usage for all its users without them needing to be apiman users?
>>>>
>>>> Tim
>>>>
>>>> On 23/07/2015 14:34, Eric Wittmann wrote:
>>>>> +1 thanks.
>>>>>
>>>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote:
>>>>>> No further comments so I created an issue for this:
>>>>>>
https://issues.jboss.org/browse/APIMAN-569
>>>>>>
>>>>>> On 20/07/2015 10:09, Eric Wittmann wrote:
>>>>>>> Hi Tim.
>>>>>>>
>>>>>>> Interesting scenario. The typical scenario is that the
apiman
>>>>>>> UI is
>>>>>>> only used by service providers and application developers.
End
>>>>>>> users
>>>>>>> will typically not use the apiman UI. However, that
doesn't mean
>>>>>>> apiman can't track end users. If authentication is
enabled (either
>>>>>>> BASIC or OAuth2), then rate limiting can be configured on a
>>>>>>> per-user
>>>>>>> basis. When you configure the rate limit policy, you can
choose
>>>>>>> "user" as an option and then provide the HTTP
header containing the
>>>>>>> user. When configuring the authentication policy (which must
come
>>>>>>> first in the policy chain) you would need to enable
forwarding
>>>>>>> of the
>>>>>>> username.
>>>>>>>
>>>>>>> In addition, the next version of apiman will also include
the
>>>>>>> authenticated user in the metrics data. This would allow you
to
>>>>>>> query
>>>>>>> the elasticsearch metrics information by username. We
won't
>>>>>>> have any
>>>>>>> specific support in the UI for breaking down metrics by user,
at
>>>>>>> least
>>>>>>> not right away, but it will be in the data at least.
>>>>>>>
>>>>>>> Of course, you *can* use apiman the way you are suggesting.
But as
>>>>>>> you observed there are some challenges. We don't
currently have a
>>>>>>> way
>>>>>>> to assign roles to users automatically when they register.
It
>>>>>>> would
>>>>>>> need to be a feature request I think:
>>>>>>>
>>>>>>>
https://issues.jboss.org/browse/APIMAN
>>>>>>>
>>>>>>> I think if we added a very generic "user
registration" extension
>>>>>>> point
>>>>>>> to apiman, then you could write your own custom handler to
do
>>>>>>> whatever
>>>>>>> you want. Such a handler would be invoked the first time a
new
>>>>>>> user
>>>>>>> logged into apiman. You could drive off their email
address,
>>>>>>> roles,
>>>>>>> whatever. You could also provide a handler via a plugin.
>>>>>>>
>>>>>>> Thoughts? :)
>>>>>>>
>>>>>>> -Eric
>>>>>>>
>>>>>>>
>>>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I've been looking into apiman and like what I see,
but have a
>>>>>>>> conceptual
>>>>>>>> question about its usage.
>>>>>>>> I need something to manage the end users of my
applications, not
>>>>>>>> just
>>>>>>>> the people who are developing and managing those
applications. Is
>>>>>>>> apiman
>>>>>>>> suitable for this? e.g. each actual user of the
applications would
>>>>>>>> register to apiman and use their own access keys. I need
this as I
>>>>>>>> will
>>>>>>>> want to handle metrics and usage on the level of the
individual
>>>>>>>> user.
>>>>>>>>
>>>>>>>> Also, if this was to be a sensible approach how does one
>>>>>>>> configure the
>>>>>>>> registration process. I understand apiman is using
keycloak for
>>>>>>>> this,
>>>>>>>> but I see no link in the UI to configure keycloak. And I
would
>>>>>>>> need a
>>>>>>>> way that new users could automatically be assigned to an
>>>>>>>> organisation
>>>>>>>> (e.g. a default organisation, or a specific one based on
their
>>>>>>>> email
>>>>>>>> address).
>>>>>>>>
>>>>>>>> Tim
>>>>>>>> _______________________________________________
>>>>>>>> Apiman-user mailing list
>>>>>>>> Apiman-user(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Apiman-user mailing list
>>>>>> Apiman-user(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user