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