Activities of "Theunis"

Hi,

We have the exact same problem.

I have 2 machines pointing at the exact same code base:

• One runs zero tool version 4.0.1
• The other runs zero tool version 3.5.1

It does not matter which entity you choose. Every single entity has the problem as described by MYBUSINESSDNA above when using version 4.0.1

All entities can be regenerated when using version 3.5.1

Please assist with a solution as our entire development is standing still as we have deadlines to meet.

Hi @ismcagdas and Support

It is now 13 days since we first logged this question and we still don't have any resolution. This is highly concerning. We really need help on this but the turnaround time on communications is really unhelpful. This is a dependency we urgently need to resolve. We cannot wait days for answers. Can you please urgently assist?

Thank you.

Hi @ismcagdas

It is not clear what the solution is you suggest and how to implement it.

• How/where do we change the admin screens such that when a user gets created on the user management screens, a user also gets created on AWS Cognito? And how do we tie the user we create on Cognito to the user in AspNet Boilerplate such that when we receive a JWT token from Cognito we can identify the user?
• Are you still suggesting we implement OpenID Connect? If so, do we still retain the JWT authentication extension we already have or does it become redundant? Does the custom middleware you suggest differ from the jwt authentication we already have (for which we've included the code in our question)? If so, how?
• Does Identity Server play a role here? Is the use of OpenID Connect, JWT token validation and identity server mutually exclusive? Which parts (open id connect, jwt auth, identity server and others) are needed and need to be customised and how do they relate to each other?

It is really unclear how OpenID connect, JWT middleware, Identity Server and ABP Authentication magic relates to each other and what is involved in the solution you suggest.

Hi @Theunis

Just a question to understand your use case. Is there a user record in AspNet Zero's username which is authenticated via AWS Cognito ? If not, it will be a problem because AspNet Zero will try to set CreationUserId, LastModifierUserId of several entities.

Maybe, instead of directly using AWS Cognito to retrieve a token, you can use OpenID Connect to login via AWS Cognito so, a local user will be created on AspNet Zero's database and you will not face such a problem.

I agree that we somehow need a user created on AspNet Zero's database as well. (Since permissions on AspNet Zero is also associated to a user in the database.). So let me explain our use cases:

AWS Cognito will be our sole Authentication Provider. We have two use cases:

1. Mobile users: users will install a mobile app and register on Cognito. Upon successful registration the mobile device will make an API call to the ASP.NET Zero Web app to register the user on the ASP.NET Zero app (this API call should be authenticated such that it is only allowed with a valid AWS Cognito Access Token). The ASP.NET Zero app will assign the appropriate permissions for a "mobile user" to such a user. These mobile users will always authenticate to all allowed API calls using the validated Cognito Access Token.
2. Web users on the ASP.NET Zero Web App: users on this application are our employees. An admin user should be able to add and remove users (and set their permissions) on the ASP.NET Zero Web App's User Management screens. Yet, login and authentication on the ASP.NET Zero Web App should happen on Cognito as that is the official Authentication Provider we need to use.