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" <rod...@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
