+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(a)redhat.com
<mailto:eric.wittmann@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...
>>
>>
>> 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(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Apiman-user mailing list
>>>>>>> Apiman-user(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
>>>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user(a)lists.jboss.org
<mailto:Apiman-user@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
>>>
https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/apiman-user
>
_______________________________________________
Apiman-user mailing list
Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/apiman-user