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

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 >