You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're debating using this AWS maintained Identity Provider than using and adapting AspNetCore.Identity.DynamoDB to our use case.
Top level we are:
migrating to a password-less authentication approach, via a custom auth flow - such that we don't have to maintain passwords
using a global DynamoDB table as out primary user store
using a User Migration Trigger to establish users in a provisioned User Pool based on the locality of the user and nearest deployed region.
using a Pre-Token Generation Trigger to get any needed user information into the token as custom claims vs using custom attributes that we synchronize with Cognito as part of the custom login flow.
using User Pool Group membership for roles
attempting to establish a configuration that means we are not dependent on Cognito being our source of truth for users, and allow us to fire up or redeploy regional stacks at will as we evolve.
Based on this we see the "local" user pool acting as a "proxy" - as we should not then have to go directly to the DynamoDB as part of the authentication/authorization process with the .Net Core integration on basis that user signup provisions the user in the DynamoDB and the "local" user pool, and as a above we use triggers as part of the custom Auth flow challenges.
We are assuming we cause a custom policy to decode custom claims.
We hope that at some point "soon" external IdP's will be supported.
We're not using Blazor, but a reactive javascript UI impleemntaiton that will make REST calls to an .Net Core minimal API backend to perform the various Registration and AuthNZ functions. We plan on using the [Authorize] attribute on the REST methods as are assuming the use of the provider will tie all this together.
Since we plan to leverage Cognito for AuthNZ is seems suboptimal to use the DynamoDB Identity provider.
Does anyone see any limitation in this regard to the use of this cognito identity provider (external IdP limitation asside)?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We're debating using this AWS maintained Identity Provider than using and adapting AspNetCore.Identity.DynamoDB to our use case.
Top level we are:
Based on this we see the "local" user pool acting as a "proxy" - as we should not then have to go directly to the DynamoDB as part of the authentication/authorization process with the .Net Core integration on basis that user signup provisions the user in the DynamoDB and the "local" user pool, and as a above we use triggers as part of the custom Auth flow challenges.
We are assuming we cause a custom policy to decode custom claims.
We hope that at some point "soon" external IdP's will be supported.
We're not using Blazor, but a reactive javascript UI impleemntaiton that will make REST calls to an .Net Core minimal API backend to perform the various Registration and AuthNZ functions. We plan on using the
[Authorize]
attribute on the REST methods as are assuming the use of the provider will tie all this together.Since we plan to leverage Cognito for AuthNZ is seems suboptimal to use the DynamoDB Identity provider.
Does anyone see any limitation in this regard to the use of this cognito identity provider (external IdP limitation asside)?
Beta Was this translation helpful? Give feedback.
All reactions