Hi Vinuri, good to see that IAM integration seems to be a feature that is also needed by other parties.
As announced on this list yesterday I am also working on integrating Openwhisk into an existing IAM system. Please see my last reply on the " Extending Authentication and Entitlement - Heads up” thread for details on the approach I am taking. As you can see there, we plan to introduce an extension point for entitlement providers that would be the point of control to get answers on the “who is allowed to do what on the namespace” questions. In an ideal world I would also here see the point to answer questions regarding namespace creation/update/deletion Unfortunately there is no API for this use cases. So maybe we should take this a starting point for the dicussion to add this “missing” API = crud for namespaces) before adding additional plug points. Moving this functionality to the server side would also make the client more lite-weight. Personally I do not see much value in replicating functionality that already exist in the IAM systems like adding namespaces to roles/users and giving access rights on them to the tooling. Additionally I do not see how this can be done for different systems in a common way. Please let me know what you think about my comments. Lets keep in discussion. Regards, Martin > On 20. Jun 2018, at 13:25, Vinuri Perera <vinuri.dew...@gmail.com> wrote: > > Hi Team, > > I'm looking into improving the openwhisk platform to support some common > IAM usecases which might be needed by enterprises. This will integrate IAM > capabilities to the platform and also to the wsk CLI. > > *##Problem* > > The requirement is to control access of users to the OpenWhisk platform, > who are already in the enterprise userstore. The reason is, most > organizations have their well-defined userstores, groups, roles etc > available and they want to plug it to this system. > > The current wskadmin tool is capable of generating namespaces. But, it > cannot map any roles to that namespace and make decisions on whether to > allow access to a certain namespace or not (authorize). > > Integration with an Identity Provider (IDP) is required in this aspect > where the IDP manage the userstores and authenticate/authorize users so we > maintain the namespace-role mapping in OpenWhisk side. > > > *##Approach* > > Approach for this is similar to the API Gateway, where we package the > required functions separately and deploy as web actions. These functions > can modify to integrate with any identity provider available to manage and > control access. OpenWhisk CLI will require to modify accordingly to cater > the identified use cases. > > > > *## Identified use-cases and suggested updates to the CLI* > > > 1. Creating the roles with namespace mapping. > > Admin users should define the required roles for the namespace. e.g - > Users who contain the 'manager' role should be able to access the > 'userManagement' namespace. > > *CLI Command* > > wsk namespace create [Namespace] [Roles] > > 2. Users generate namespace tokens and login to the system. > > Any user should be able to generate an access token for namespaces if > they belong to any of the roles that have been mapped to the namespace. The > decision will be taken by the IDP by authenticating and authorizing the > user against the roles mapped to the namespace > > There are two parts to this command, if the user does not contain the > access token for the namespace it will generate the required token after > verifying from the IDP and set the auth property for the user. If user > already contain the access token for the requested namespace this command > will set the existing auth token for the user. > > *CLI Command* > > wsk login [Username] [Namespace] > > Should prompt for the password > > 3. Revoking user namespace token > > Admin user should be able to revoke user namespace tokens. This action is > only available the admin user, CLI will check if the current namespace is > in the system namespace and handle the restrictions for accessing the > action. The action itself will verify the authorization to perform the > action from the IDP. > > * CLI Command* > > wsk user revoke [Username] [Namespace] > > > > > Above is the high-level description of the proposed solution for > integrating some of the IAM use cases with the OpenWhisk platform. > > Please Let me know if you have any comments and suggestions or an already > working/discussed solution. > > > Best Regards, > > ~Vinuri~
