Proposal to integrate IAM use cases with the OpenWhisk platform

[Vinuri Perera <vi...@gmail.com>]

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~

Re: Proposal to integrate IAM use cases with the OpenWhisk platform

[Vinuri Perera <vi...@gmail.com>]

Hi Martin,

Thanks for the quick response, Currently we are looking into addressing the
“who is allowed to do what on the namespace” with the user roles concept
and modifying the login with more user-friendly manner.
Currently discussed solution seems to be a bit different from the approach
I'm looking into. Will you be able to give explain more details on the
approach?

Best Regards,
~Vinuri~


On Wed, Jun 20, 2018 at 8:18 PM, Martin Henke <ma...@web.de> wrote:

> 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 <vi...@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~
>
>

Re: Proposal to integrate IAM use cases with the OpenWhisk platform

[Martin Henke <ma...@web.de>]

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 <vi...@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~