8:22 a.m.
You are 100% right about that. Ultimately the issue is that we do *not*
currently support OAuth as a mechanism to identify the client app being
used to invoke the API.
I do agree that we need tighter integration with KC in a number of
places to make everything easier to consume. I think that perhaps we
are too decoupled from KC at the moment.
Do you have any thoughts on how you'd like to see it work? Just your
impressions - I won't hold you to them. ;)
We're always looking for ways to improve, and one of the best things for
us is when users describe what they would like to see!
-Eric
On 1/20/2016 9:13 AM, michele danieli wrote:
Hello Eric,
still related to the point above, I think a key element is that there is
no actual correlation between the application in APIMAN and the client
in KC. You createan application, but the application has only an key
for associating itself to the API via a contract, while from an OAuth
perspective you need a client and eventually a secret, which you only
configure in KC. This means configuration of an application and
enablement of OAuth requires users to interact separately with KC and
APIMAN, which is odd. Of course I understand that complexities lay
behind, for example in which realm a client would be defined?
On Thu, Jan 14, 2016 at 7:16 PM, michele danieli
<michele.danieli(a)gmail.com <mailto:michele.danieli@gmail.com>> wrote:
Hello Eric,
my scenario is the following.
A set of API has been defined to expose core business functions, to
clerks and sales force automation. Some functions are specifically
sensitive. All access requires end user authentication. Some
function are only accessible to users when using trusted clients:
for example access from browsers js apps is not enabled to some
functions, while native clients for mobile SFA do.
For trusted application i have implemented OAUTH with signed JWT
client authentication (updated KC to latest) almost meeting security
requirements (added a ticket to KC for supports of nonces) but oauth
client and application are actually unrelated, so no way I can
relate the client id to application to enforce access to sensitive
api to only users authenticated with the trusted client.
Of course I can set the api_key header to the one I have associated
to the trusted client, but this are unrelated (security department
not so happy). I could probably use the api_key as client_id in KC
and implement a custom policy to verify the access token audience (i
guess that is where the client is mapped in the signed token)
matches the apikey.
In general i was thinking if diffeent strategies for application
identification made sense (at api level) .
Bests
Mike
On Thu, 14 Jan 2016 at 14:34, Eric Wittmann
<eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> wrote:
Hi Michele.
That is correct. Typically the end-user population is tied to
the API
being invoked rather than the Client (software) being used to
connect.
If that is not the case, then you could configure the OAuth
policy on
the Client Application rather than on the API (Service). That
way you
could have a different user population for each connecting
client. If
that's your use-case I'd love to hear more about it. :)
-Eric
On 1/13/2016 3:05 PM, michele danieli wrote:
> When considering non public API and applying a OAuth
authentication
> policy, the application identifier must be provided using the
api_key as
> a header?
>
> If so, does not it means that the user authorized client and
the actual
> api consumer application have no strict relationship?
>
>
> Thanks
> Michele
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user(a)lists.jboss.org <mailto:Apiman-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/apiman-user
>