authentication models for openwhisk

[Rodric Rabbah <ro...@gmail.com>]

I'm capturing below a summary of slack discussions around authentication
and identity management for openwhisk for the benefit of the dev list.

The discussion started around the IBM Bluemix login integration for
openwhisk and how the wsk CLI will be a plugin as part of an existing
bluemix CLI. In doing this, the goal is to maintain the platform
independence of the wsk CLI but allow a platform to provide its own
identity management.

To which, it was noted [1] that Adobe has had the same discussion within
their team since they require a different authentication method for their
OpenWhisk deployment. One of the questions that arose in the ensuing
discussion was: what would it take to make the wsk CLI plugable with
respect to authentication (rather than having each platform provider wrap
wsk for their own purposes).

It was noted that JWT (Json Web Tokens) may be one approach [2], or using
pre-existing OAuth providers to provide tokens (that expire after some
duration) [3]. So how can one use OAuth tokens to authenticate the wsk CLI?
Apropos this point, it may be necessary to modify the Authentication [4]
interface in the controller to allow for multiple identity provider models.
Some extensions in this space are already underway (see [5] for certificate
based authentication for example).

An example was proposed as follows [6]:
   currently CLI does
       req.Header.Add("Authorization", fmt.Sprintf("Basic %s",
encodedAuthToken))
   that is one place it would be nice to make configurable, e.g.
       wsk --basic-auth
    and
       wsk --bearer-auth (or Authorization: Bearer)

And to possibly extend .wskprops as in [7] to augment the existing AUTH
property:
       AUTH=Bearer <token>
    or
       AUTH=Basic <basic:Credentials>
    which can be automatically configured via a new wsk CLI command as in
       wsk auth login
    which can print a URL that users open in the browser to authenticate,
then they come back to paste the Bearer Token. The CLI can add the token
into .wskprops.

It was noted in [7] that the Azure CLI works similarly. Here's an example:
    az login
   To sign in, use a web browser to open the page https://aka.ms/devicelogin
and enter the code xxxxx to authenticate.

A prototype of this "wsk login" approach was previously prototyped as proof
of concept in [8] using GitHub as an OAuth provider. The flow if I recall
is:

    wsk login <provider> # one of github, google

this opens a browser which allows the user to authenticate and returns an
OAuth token. This was injected into the authentication database which then
allows the wsk CLI to use the token for subsequent operations.

-r (on behalf of several openwhiskers from our community slack channel -
typos all my own)

[1] https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1501594586367600
[2] https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1501598248729369
[3] https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1501599810814266
[4]
https://github.com/apache/incubator-openwhisk/blob/master/core/controller/src/main/scala/whisk/core/controller/AuthenticatedRoute.scala
[5] https://github.com/apache/incubator-openwhisk/pull/2517
[6] https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1501602885940574
[7] https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1501604477993184
[8]
https://github.com/apache/incubator-openwhisk/compare/master...starpit:oauth_login?expand=1
(note that the secrets shows here are not valid and for illustration only)