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

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 >

+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 >

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 >

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 >

I'm also toying around with the idea of pre-installing some of the plugins so they are automatically included in the apiman quickstart.

I'm also toying around with the idea of pre-installing some of the plugins so they are automatically included in the apiman quickstart.

+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