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