[Apiman-user] OAuth with non public API

[Eric Wittmann]

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 at gmail.com <mailto:michele.danieli at 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 at redhat.com <mailto:eric.wittmann at 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 at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>          > https://lists.jboss.org/mailman/listinfo/apiman-user
>          >
>
>