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 <csantan...@gmail.com> 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 <rod...@gmail.com> 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 <boa...@gmail.com>
