Re: [Apiman-user] apiman suitable for managing end users?

+1 to this idea. @Jakub - can you add a jira feature request for this? On 10/10/2015 10:20 AM, Jakub Čecháček wrote: > Hi, > > > I'm also toying around with the idea of pre-installing some of the >> plugins so they are automatically included in the apiman quickstart. > > 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. > > Jakub. > > On Sat, Oct 10, 2015 at 4:13 PM, Eric Wittmann <eric.wittmann(a)redhat.com > <mailto:eric.wittmann@redhat.com>> wrote: > > 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 > <mailto:Apiman-user@lists.jboss.org> > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Apiman-user mailing list > >>>>>>> Apiman-user(a)lists.jboss.org > <mailto:Apiman-user@lists.jboss.org> > >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Apiman-user mailing list > >>>>> Apiman-user(a)lists.jboss.org <mailto: Apiman-user(a)lists.jboss.org&gt; > >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>>>> > >>> > >>> _______________________________________________ > >>> Apiman-user mailing list > >>> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/apiman-user > >>> > > > > _______________________________________________ > > Apiman-user mailing list > > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/apiman-user > > > _______________________________________________ > Apiman-user mailing list > Apiman-user(a)lists.jboss.org <mailto:Apiman-user@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