[Apiman-user] apiman suitable for managing end users?
Rachel Yordan
ryordan at redhat.com
Wed Oct 14 08:54:13 EDT 2015
+1 Late here, but I second this. Great idea Jakub!
On Tue, Oct 13, 2015 at 7:58 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:
> +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 at redhat.com
> > <mailto: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
> > <mailto:Apiman-user at lists.jboss.org>
> > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>> _______________________________________________
> > >>>>>>> Apiman-user mailing list
> > >>>>>>> Apiman-user at lists.jboss.org
> > <mailto:Apiman-user at lists.jboss.org>
> > >>>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
> > >>>>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Apiman-user mailing list
> > >>>>> Apiman-user at lists.jboss.org <mailto:
> Apiman-user at lists.jboss.org>
> > >>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
> > >>>>>
> > >>>
> > >>> _______________________________________________
> > >>> Apiman-user mailing list
> > >>> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org
> >
> > >>> https://lists.jboss.org/mailman/listinfo/apiman-user
> > >>>
> > >
> > > _______________________________________________
> > > Apiman-user mailing list
> > > Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/apiman-user
> > >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org <mailto: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/20151014/80a9bba3/attachment-0001.html
More information about the Apiman-user
mailing list