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