[Apiman-user] OAuth with non public API

[michele danieli]

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>
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>
> 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
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160120/7c9d60ed/attachment.html