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