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

Sat Oct 10 10:20:15 EDT 2015

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 at 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/authorization/2015/06/09/keycloak-oauth2.html
> >>
> >>
> >> 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 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
> >>>>>
> >>>
> >>> _______________________________________________
> >>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151010/66737f2b/attachment-0001.html 