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/authorization/2015/06/09/keycloak-oauth2.html
>>
>>
>> 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@lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apiman-user mailing list
>>>>>>> Apiman-user@lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
_______________________________________________
Apiman-user mailing list
Apiman-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/apiman-user