[Apiman-user] apiman suitable for managing end users?
Eric Wittmann
eric.wittmann at redhat.com
Tue Oct 13 07:58:33 EDT 2015
+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
>
>
More information about the Apiman-user
mailing list