Extend permission for auth/unauth users

[lielran]

I would like to see a way to extend the permission that provides to the auth/unauth users. amplify update and extend the role policies when added new category(e.g. storage) but how should I provide policies to that role that are managed outside the scope of amplify-cli for example - access to external API gateway execute-API, backend Serverless REST api that has it's own repo and lifecycle.

the solution should be supported by amplify multi env. we also using multi aws account per env/developer. currently, the only workaround we found is to provide admin for all the arn's cross accounts arn:aws:execute-api:*:*:*

Which Category is your question related to? Auth

What AWS Services are you utilizing? Many of aws resources that outside amplify-cli scope

Provide additional details e.g. code snippets

[UnleashedMind]

Thanks @lielran for the feedbacks, we will discuss among the team.

[kaustavghosh06]

We launched multi-auth support for AppSync API (which included public APIs - with API Keys + IAM) as a part of our CLI version 3.7+. Please take a look at our documentation around it out here - https://aws-amplify.github.io/docs/cli-toolchain/graphql#public-authorization

[lielran]

@kaustavghosh06 what if I don't want/need to use AppSync?

[kaustavghosh06]

I misread the issue. Sorry, re-opening this.

[kaustavghosh06]

@lielran I think a good way to go around this would be to use your custom stack and use the auth/unauth role as references add your custom policies to that? More info on custom stacks out here - https://aws-amplify.github.io/docs/cli-toolchain/quickstart#custom-cloudformation-stacks

[lielran]

Thanks. Custom stack will definitely works. Still, I think this kind of task is basic extend of Amplify abilities and it should be easy to perform with amplify tools. This mean that I should have self-service abilities in the same stack

On Thu, Mar 12, 2020, 02:44 Kaustav Ghosh notifications@github.com wrote:

@lielran https://github.com/lielran I think a good way to go around this would be to use your custom stack and use the auth/unauth role as references add your custom policies to that? More info on custom stacks out here - https://aws-amplify.github.io/docs/cli-toolchain/quickstart#custom-cloudformation-stacks

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-cli/issues/1445#issuecomment-597950120, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHVI647BTKEVMI66OWSZRTRHAV6VANCNFSM4HMKIYOQ .

[Nxtra]

@lielran I think a good way to go around this would be to use your custom stack and use the auth/unauth role as references add your custom policies to that? More info on custom stacks out here - https://aws-amplify.github.io/docs/cli-toolchain/quickstart#custom-cloudformation-stacks

This seems the way to go. But I can't figure out how to reference the authRole/unAuthRole. How can I reference authRole in a custom stack?

The below (from docs) doesn't work since I want to refernce authRole which comes from the root stack. (no category I think?)

const dependencies: AmplifyDependentResourcesAttributes = AmplifyHelpers.addResourceDependency(this,
  amplifyResourceProps.category,
  amplifyResourceProps.resourceName,
  [{
    category: "function", // api, auth, storage, function, etc.
    resourceName: "<resource-name>" // find the resource at "amplify/backend/<category>/<resourceName>"
  } /* add more dependencies as needed */] 
);

[Nxtra]

@lielran I think a good way to go around this would be to use your custom stack and use the auth/unauth role as references add your custom policies to that?

How do you reference the ARN of the auth/unauth role in such an override without hardcoding it?

[lielran]

@lielran I think a good way to go around this would be to use your custom stack and use the auth/unauth role as references add your custom policies to that?

How do you reference the ARN of the auth/unauth role in such an override without hardcoding it?

@Nxtra I'm not sure, probably either naming convention or hardcoded. After a long time of fighting to make Amplify work for me, I switch to CDK which provides me with much more flexibility.