You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Martin Henke <ma...@web.de> on 2018/06/12 14:38:20 UTC
Extending Authentication and Entitlement - Heads up
Hi,
as some of you might have noticed with my last commit so please take this mail as a heads-up.
I am on the road to introduce extensibility for the authentication and entitlement in Openwhisk.
The changes are motivated by the need to integrate Openwhisk tighter into
an existing (but unfortunately partly proprietary) identity and management
system used in the IBM cloud.
The first change will be to introduce an SPI to exchange the existing EntitlementProvider with an alternative
implementation. Since the EntitlementProvider already is implemented like a SPI-like interface
this change is very straightforward.
The authentication changes will address two areas.
First the REST API will be enabled to read other authentication formats and tokens
(e.g. bearer tokens), second there has to be the ability added to pass different authentication information
to the user actions.
I plan to address this with introducing an SPI to swap the AuthorizationDirective in the RestApi
and adding a mechanism to transport variant information in the authentication key to the invoker.
All changes are designed to be transparent to the existing authentication and entitlement
implementations using the subject db.
I will open pull request for all these changes in the next days.
Feel free to comment now to this mail or later to the pull requests.
Kind regards,
Martin
Re: Extending Authentication and Entitlement - Heads up
Posted by Andy Steed <an...@adobe.com.INVALID>.
Thanks Martin!
Regarding the Entitlement provider, could you share the current state of the SPI?
Cheers,
Andy
________________________________
From: Martin Henke <ma...@web.de>
Sent: Tuesday, June 19, 2018 8:16:53 AM
To: dev@openwhisk.apache.org
Subject: Re: Extending Authentication and Entitlement - Heads up
Andy,
sorry for answering late. I was some days out and then dragged into other work.
Let me try to explain the things we want to do with our IAM integration.
After having the needed extension points available (as explained in my last mail) we plan to implement an authentication
directive that will additionally to the standard implementation be able to accept bearer tokens and validate them
against a list of valid public keys and certain content requirements.
Since the authentication directive is the point to create a user identity, our implementation will reach out to
other systems to create a “complete" user identity (e.g. containing limits and the default namespace).
The created user identity will contain an AuthKey variation with IAM credentials for the user and the namespace
This AuthKey will be passed to user/system containers and can be used to create triggers or to reach out to other services.
For the entitlement use case we plan to implement a a provider that checks the tuple of access method, user identity
and accessed resource (which is in our case the namespace) against an external policy system.
Concerning the linked PR, I am totally fine to make the adapted entitlement provider the SPI interface.
I do not see any need for big adaption effort regardless of order the PRs will go in.
I hope that answers your questions.
Regards,
Martin
> On 13. Jun 2018, at 01:22, Andy Steed <an...@adobe.com.INVALID> wrote:
>
> Hi Martin!
>
> As Rodric mentioned, I've been working in Entitlements regarding namespace limits. I'm also interested in support for IAM integration. Do you have any use case(s) that you could share regarding what you're looking to support? Similarly, do you have any details on additional entitlement controls you're may be looking to expose (both short and long term) made available via the new IAM provider? I have a task to support for Adobe's IAM provider and would like to see how your plans potentially map onto that.
>
> Cheers,
> Andy
>
> On 6/12/18, 8:18 AM, "Rodric Rabbah" <ro...@gmail.com> wrote:
>
>> The first change will be to introduce an SPI to exchange the existing
> EntitlementProvider with an alternative
> implementation. Since the EntitlementProvider already is implemented like a
> SPI-like interface
> this change is very straightforward.
>
> Since IAM integration is of general interest and applicable for others who
> deploy and manage OpenWhisk, is the current interface sufficient? For
> example, this PR [1] from Andy Steed was steered toward Entitlement checks.
> Similarly, the current and future limits applied to a namespace may be
> equally fitting (where today they are tied to the subject records). So we
> should think about how to support both the short term and long term.
>
> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F3661&data=02%7C01%7Candsteed%40adobe.com%7Cc0f8898085ff4120cf5008d5d077c968%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636644135257283014&sdata=ojlxOA3cRPopJXrhX9Pe%2FUmJ76uSMvGonlbe5%2BQsQ4M%3D&reserved=0
>
>> First the REST API will be enabled to read other authentication formats
> and tokens
> (e.g. bearer tokens), second there has to be the ability added to pass
> different authentication information
> to the user actions.
>
> This is great and long overdue - Are you envisioning that we can then also
> attach different tokens with resources in a more fine grained capacity than
> today (which is an entire namespace)?
>
> -r
>
>
Re: Extending Authentication and Entitlement - Heads up
Posted by Martin Henke <ma...@web.de>.
Andy,
sorry for answering late. I was some days out and then dragged into other work.
Let me try to explain the things we want to do with our IAM integration.
After having the needed extension points available (as explained in my last mail) we plan to implement an authentication
directive that will additionally to the standard implementation be able to accept bearer tokens and validate them
against a list of valid public keys and certain content requirements.
Since the authentication directive is the point to create a user identity, our implementation will reach out to
other systems to create a “complete" user identity (e.g. containing limits and the default namespace).
The created user identity will contain an AuthKey variation with IAM credentials for the user and the namespace
This AuthKey will be passed to user/system containers and can be used to create triggers or to reach out to other services.
For the entitlement use case we plan to implement a a provider that checks the tuple of access method, user identity
and accessed resource (which is in our case the namespace) against an external policy system.
Concerning the linked PR, I am totally fine to make the adapted entitlement provider the SPI interface.
I do not see any need for big adaption effort regardless of order the PRs will go in.
I hope that answers your questions.
Regards,
Martin
> On 13. Jun 2018, at 01:22, Andy Steed <an...@adobe.com.INVALID> wrote:
>
> Hi Martin!
>
> As Rodric mentioned, I've been working in Entitlements regarding namespace limits. I'm also interested in support for IAM integration. Do you have any use case(s) that you could share regarding what you're looking to support? Similarly, do you have any details on additional entitlement controls you're may be looking to expose (both short and long term) made available via the new IAM provider? I have a task to support for Adobe's IAM provider and would like to see how your plans potentially map onto that.
>
> Cheers,
> Andy
>
> On 6/12/18, 8:18 AM, "Rodric Rabbah" <ro...@gmail.com> wrote:
>
>> The first change will be to introduce an SPI to exchange the existing
> EntitlementProvider with an alternative
> implementation. Since the EntitlementProvider already is implemented like a
> SPI-like interface
> this change is very straightforward.
>
> Since IAM integration is of general interest and applicable for others who
> deploy and manage OpenWhisk, is the current interface sufficient? For
> example, this PR [1] from Andy Steed was steered toward Entitlement checks.
> Similarly, the current and future limits applied to a namespace may be
> equally fitting (where today they are tied to the subject records). So we
> should think about how to support both the short term and long term.
>
> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F3661&data=02%7C01%7Candsteed%40adobe.com%7Cc0f8898085ff4120cf5008d5d077c968%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636644135257283014&sdata=ojlxOA3cRPopJXrhX9Pe%2FUmJ76uSMvGonlbe5%2BQsQ4M%3D&reserved=0
>
>> First the REST API will be enabled to read other authentication formats
> and tokens
> (e.g. bearer tokens), second there has to be the ability added to pass
> different authentication information
> to the user actions.
>
> This is great and long overdue - Are you envisioning that we can then also
> attach different tokens with resources in a more fine grained capacity than
> today (which is an entire namespace)?
>
> -r
>
>
Re: Extending Authentication and Entitlement - Heads up
Posted by Andy Steed <an...@adobe.com.INVALID>.
Hi Martin!
As Rodric mentioned, I've been working in Entitlements regarding namespace limits. I'm also interested in support for IAM integration. Do you have any use case(s) that you could share regarding what you're looking to support? Similarly, do you have any details on additional entitlement controls you're may be looking to expose (both short and long term) made available via the new IAM provider? I have a task to support for Adobe's IAM provider and would like to see how your plans potentially map onto that.
Cheers,
Andy
On 6/12/18, 8:18 AM, "Rodric Rabbah" <ro...@gmail.com> wrote:
> The first change will be to introduce an SPI to exchange the existing
EntitlementProvider with an alternative
implementation. Since the EntitlementProvider already is implemented like a
SPI-like interface
this change is very straightforward.
Since IAM integration is of general interest and applicable for others who
deploy and manage OpenWhisk, is the current interface sufficient? For
example, this PR [1] from Andy Steed was steered toward Entitlement checks.
Similarly, the current and future limits applied to a namespace may be
equally fitting (where today they are tied to the subject records). So we
should think about how to support both the short term and long term.
[1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F3661&data=02%7C01%7Candsteed%40adobe.com%7Cc0f8898085ff4120cf5008d5d077c968%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636644135257283014&sdata=ojlxOA3cRPopJXrhX9Pe%2FUmJ76uSMvGonlbe5%2BQsQ4M%3D&reserved=0
> First the REST API will be enabled to read other authentication formats
and tokens
(e.g. bearer tokens), second there has to be the ability added to pass
different authentication information
to the user actions.
This is great and long overdue - Are you envisioning that we can then also
attach different tokens with resources in a more fine grained capacity than
today (which is an entire namespace)?
-r
Re: Extending Authentication and Entitlement - Heads up
Posted by Rodric Rabbah <ro...@gmail.com>.
> The first change will be to introduce an SPI to exchange the existing
EntitlementProvider with an alternative
implementation. Since the EntitlementProvider already is implemented like a
SPI-like interface
this change is very straightforward.
Since IAM integration is of general interest and applicable for others who
deploy and manage OpenWhisk, is the current interface sufficient? For
example, this PR [1] from Andy Steed was steered toward Entitlement checks.
Similarly, the current and future limits applied to a namespace may be
equally fitting (where today they are tied to the subject records). So we
should think about how to support both the short term and long term.
[1] https://github.com/apache/incubator-openwhisk/pull/3661
> First the REST API will be enabled to read other authentication formats
and tokens
(e.g. bearer tokens), second there has to be the ability added to pass
different authentication information
to the user actions.
This is great and long overdue - Are you envisioning that we can then also
attach different tokens with resources in a more fine grained capacity than
today (which is an entire namespace)?
-r