Hi,
I'm Felix Delval from Adobe, my team has been working on adding
authentication through Adobe Identity Management System (IMS) to
OpenWhisk API as an internal project. IMS can in this context can be
thought as an OAuth Bearer Token authentication service.
We are now thinking about making that implementation a more generic
Oauth Bearer Token (RFC 6750 [1]) and contributing it back to the
OpenWhisk project. I have seen a few threads mentioning this subject in
the past: [2] [3]
Our goal is to be able to provide:
* a customizable OAuth Integration that could work with Adobe IMS,
Google OAuth Facebook OAuth, ...
* a chain authentication mechanism so BasicAuth and OAuth can function
in parallel
* a first-class OAuth authentication, in which BasicAuth could be
forbidden
To be able to design such a solution, and also when we were trying to
solve it internally, we faced some issues where we thought the OpenWhisk
codebase was not extensible enough or providing the wrong interfaces.
I'd like to open the discussion on several of those topics
I - Authentication SPI
AuthenticationDirectiveProvider [4] presents two extension point the
`authenticate` method and the `identityByNamespace` method.
The `authenticate` method aims at returning an `Identity` [5] object
back which is a good enough abstraction. The `Identity` represents the
composition of `Subject`, `Namespace` and `Limits`. We can use this as a
base for extension and be generating the Identity necessary for the rest
of the process to work.
The case of `identityFromNamespace` function, which is used for
anomymous web actions, is slight different. In the context of an Oauth
Bearer Token integration, the Identity of an anonymous web actions is
more complicated to formulate.
Is there a use case I'm missing for `identityFromNamespace` is an OAuth
context?
II - Extensibility issues
In order to be able to extend the authentication mechanism and offer the
possibilities to create third party authentication modules some class
would need to become extensible. Currently the basic elements of the
Identity which are : Privileges, Limits, Namespaces are all with limited
access to org.apache.openwhisk.core. Thoses package will need to have
public visibility and be considered part of the extensibility API of
OpenWhisk.
III - Authorization mechanism
As of now there is a 1-1 relation between Subject (represented by
WskAuth) and Namespace. We would need to create a consistent way to link
the Subject, represented by an OAuth provider User ID, to the namespace.
This would require storage but also probably an API to edit the
permissions of each Subject on Namespace. The relationship of Subject,
Namespace and Limits being an Identity, it would take the form of an
Identity API Management.
As far as I know, OpenWhisk administration is done through the
`wskadmin` utilities that access directly the storage. In other words,
there are not administration API so far. Should we consider creating an
Adiministration Identity API? Would an addition to `wskadmin` be the
correct way?
* [1] https://tools.ietf.org/html/rfc6750
* [2]
https://lists.apache.org/thread.html/565c6823d34e9c618b8b40a1b22fc6979d33307055e971a9cdc73c4d%40%3Cdev.openwhisk.apache.org%3E
* [3]
https://lists.apache.org/thread.html/8b5ddfe5e302098370b8b4bc265e5aed5f57ba7c2c73860363a9da6a%40%3Cdev.openwhisk.apache.org%3E
* [4]
https://github.com/apache/openwhisk/blob/59b67fe96f44e573f3348afed966a1cdaf80ddf2/core/controller/src/main/scala/org/apache/openwhisk/core/controller/RestAPIs.scala#L331
* [5]
https://github.com/apache/openwhisk/blob/59b67fe96f44e573f3348afed966a1cdaf80ddf2/common/scala/src/main/scala/org/apache/openwhisk/core/entity/Identity.scala
If you have any comments or suggestion, I'd love hear them.
Thanks.
Félix Delval
