Re: oauth token verification in the controller
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 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 님이 작성: > > > 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 : > > > > > > 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
Re: oauth token verification in the controller
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 님이 작성: > 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 : > > > > 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 > >
Re: oauth token verification in the controller
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 : > > 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
Re: oauth token verification in the controller
As a budding security engineer, I’ll suggest to emphasize role based security authorization rather than a permission model. It’s easier to maintain over time, and it’ll map well to OAuth scopes as well as in JWT metadata, plus it’ll likely still adapt well to whatever new security standards are invented. On Fri, Jun 21, 2019 at 06:56, Carlos Santana wrote: > Rodric I think having additional authentication methods no one will > object, but the devil are in the details :-) > > Also when you say things like “replace” with no more context some folks > that are using the software in production, quickly jump into the conclusion > on “Now I have thousands of end users suddenly can’t authenticate and > applications in the field broken :sob: “ > > The current auth SPI I believe allows the controller to be customize to > handle an authorization header of “Bearer” token instead of “Basic” > > If your are referring to OAuth 2.0 is quite large but maybe your referring > to discussing “Scopes” in an OpenWhisk world, ability to have more grain > control. > > For example ability to have a token with a scope have the ability to > delete artifacts vs a token that is only allow to create but not delete vs > a token that is only allow to invoke a trigger with “long” expiration time > and nothing else. > > - Carlos Santana > @csantanapr > > > On Jun 21, 2019, at 7:23 AM, Rodric Rabbah wrote: > > > > 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
Re: oauth token verification in the controller
Rodric I think having additional authentication methods no one will object, but the devil are in the details :-) Also when you say things like “replace” with no more context some folks that are using the software in production, quickly jump into the conclusion on “Now I have thousands of end users suddenly can’t authenticate and applications in the field broken :sob: “ The current auth SPI I believe allows the controller to be customize to handle an authorization header of “Bearer” token instead of “Basic” If your are referring to OAuth 2.0 is quite large but maybe your referring to discussing “Scopes” in an OpenWhisk world, ability to have more grain control. For example ability to have a token with a scope have the ability to delete artifacts vs a token that is only allow to create but not delete vs a token that is only allow to invoke a trigger with “long” expiration time and nothing else. - Carlos Santana @csantanapr > On Jun 21, 2019, at 7:23 AM, Rodric Rabbah wrote: > > 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
oauth token verification in the controller
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
