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

[Eric Wittmann]

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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>