Hi Felix. I interested in this as you cited one of my earlier queries around 
this. 

At Nimbella we did implement an admin api to address the account management 
issues. We don’t use wskadmin for that today but I shared in our community 
slack not too long ago an example of how to use wskadmin to achieve the same. 
I’m happy to share the apis we implemented and if they’re aligned with 
interests from the community, would be happy to upstream these.

-r

> On Apr 29, 2021, at 5:48 AM, Felix Delval <fe...@delval.eu> wrote:
> 
> 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
> 

Reply via email to