[Apiman-user] OAuth with non public API

[michele danieli]

Hello Eric,
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.

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).

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".

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).

Beats
Mike

On Wed, 20 Jan 2016 at 15:22, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> 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
> >          >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160122/0fd40dab/attachment-0001.html