openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: oauth token verification in the controller
Date Tue, 25 Jun 2019 18:01:08 GMT
Using JWT with independently distributed keys for verifying authorization
info has worked best for overall performance in my experience so far (in
microservices generally; not tested with OW). Using that pattern minimizes
auth server contact thanks to cryptographic verification of the JWT. Also
handy against brute force attacks and other denial of service vectors. Has
anyone tried that out yet using the oauth support?

I’ve done exploration in the past for designing a highly available
authorization service, and utilizing JWT (or some other message
signing/encryption protocol) to validate the auth data provided by the auth
server on login. I can dig up the blog post if anyone is interested.

On Mon, Jun 24, 2019 at 22:07, Dominic Kim <style9595@gmail.com> wrote:

> It might not be directly related to the agenda but one small thing to note
> is the response time of the auth/authz server should be considered as well.
> When I implemented LDAP integration, the LDAP server was too slow.
> It took about 100ms ~ 1s to authenticate users.
> Even though I took advantage of the cache, I could not reduce the cold
> start(in terms of authentication) latency, and I had to drop the LDAP
> integration in the end.
> In my case, LDAP is legacy, I didn't have many choices.
>
> So if the authentication backend is not fast as enough, you might need to
> ponder some ways to overcome it.
>
> Regards
> Dominic
>
> 2019년 6월 24일 (월) 오전 1:56, Martin Henke <martin.henke@web.de>님이
작성:
>
> > Rodric,
> >
> > IBM Cloud Functions hasn’t implemented OAuth, but JWT based bearer token
> > based authentication based on the IBM Cloud IAM system.
> >
> > The first problem we encountered was that our bearer token did not
> provide
> > a namespace related context
> > (which is only configured in the IAM system). The only obvious namespace
> > related information is contained in the URI (but unfortunately not always
> > when looking at the _ default).
> >
> > The next problem was the need to construct the Identity object (of which
> > the namespace information is a key component) fully in the authorization
> > code to not break the API handling (which brings us back to the missing
> > namespace information).
> >
> > We overcame the problems by asking the user to provide missing namespace
> > information via additional headers and by retrieving additional
> > authorization related data from proprietiary data stores.
> >
> > There were more problems in the realm to provide the meaningful error
> > messages.
> > Nevertheless our implementation proves that OW is already able to handle
> > JWT based bearer tokens and provide them to be used in outbound calls.
> >
> > Regards,
> > Martin
> >
> > > Am 21.06.2019 um 13:23 schrieb Rodric Rabbah <rodric@gmail.com>:
> > >
> > > I'm curious if anyone has thought about or implemented an oauth based
> > > authentication mechanism in the controller. I've thought about
> replacing
> > > the subject authentication with oauth and think it would not be a lot
> of
> > > work to do although it does have some wider implications.
> > >
> > > -r
> >
> >
>
-- 
Matt Sicker <boards@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message