openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Steed <andst...@adobe.com.INVALID>
Subject Re: Extending Authentication and Entitlement - Heads up
Date Mon, 25 Jun 2018 22:22:19 GMT
Thanks Martin!


Regarding the Entitlement provider, could you share the current state of the SPI?


Cheers,

Andy

________________________________
From: Martin Henke <martin.henke@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 <andsteed@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" <rodric@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message