<div dir="ltr">+1 Late here, but I second this. Great idea Jakub!</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 13, 2015 at 7:58 AM, 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">+1 to this idea.<br>
<br>
@Jakub - can you add a jira feature request for this?<br>
<br>
On 10/10/2015 10:20 AM, Jakub Čecháček wrote:<br>
> Hi,<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>
><br>
> A nice approach to this would be a post-install "setup wizard" when the<br>
> UI is first entered. This would enable user to add the seed data and<br>
> possibly enable additional plugins.<br>
><br>
> Jakub.<br>
><br>
> On Sat, Oct 10, 2015 at 4:13 PM, Eric Wittmann <<a href="mailto:eric.wittmann@redhat.com">eric.wittmann@redhat.com</a><br>
> <mailto:<a href="mailto:eric.wittmann@redhat.com">eric.wittmann@redhat.com</a>>> wrote:<br>
><br>
> 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>
><br>
> -Eric<br>
><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<br>
> 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<br>
> here:<br>
> >><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<br>
> configured<br>
> >> first, and then the roles found in the bearer token will get<br>
> 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<br>
> 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<br>
> 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<br>
> course,<br>
> >>>> practically speaking it makes sense to just have one KC<br>
> server. But<br>
> >>>> definitely I think you want to create other realms - and one<br>
> 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<br>
> configured<br>
> >>>>> here? The idea being that an organisation could create a<br>
> policy that<br>
> >>>>> authenticates against a realm configured for that<br>
> 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<br>
> doesn't mean<br>
> >>>>>>>> apiman can't track end users. If authentication is<br>
> 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<br>
> choose<br>
> >>>>>>>> "user" as an option and then provide the HTTP header<br>
> containing the<br>
> >>>>>>>> user. When configuring the authentication policy (which<br>
> 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<br>
> 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<br>
> 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<br>
> suggesting. But as<br>
> >>>>>>>> you observed there are some challenges. We don't<br>
> 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"<br>
> 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<br>
> 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<br>
> applications, not<br>
> >>>>>>>>> just<br>
> >>>>>>>>> the people who are developing and managing those<br>
> applications. Is<br>
> >>>>>>>>> apiman<br>
> >>>>>>>>> suitable for this? e.g. each actual user of the<br>
> applications would<br>
> >>>>>>>>> register to apiman and use their own access keys. I need<br>
> this as I<br>
> >>>>>>>>> will<br>
> >>>>>>>>> want to handle metrics and usage on the level of the<br>
> 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<br>
> keycloak for<br>
> >>>>>>>>> this,<br>
> >>>>>>>>> but I see no link in the UI to configure keycloak. And I<br>
> 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<br>
> 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>
> <mailto:<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>
> <mailto:<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> <mailto:<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> <mailto:<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> <mailto:<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> <mailto:<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>
</blockquote></div><br></div>