Sorry no code here because I am looking for a better idea or if I am on the right track?

I have two websites, lets call them A and B.

A is a website exposed to the internet and only users with valid account can access.

B is a internal (intranet) website with (Windows authentication using Active directory). I want Application B (intranet) to create users for Application A.

Application A is using the inbuilt ASP.NET JWT token authentication.

My idea is to expose a Api on the extranet website (A) and let (B) access this API. I can use CORS to make sure only (B) has access to the end point but I am not sure if this is a good enough protection? We will perform security penetrations test from a third party company so this might fail the security test?

Or

I can use entity framework to a update the AspnetUsers table manually. Not idea if this is feasible or the right way or doing things.

Any other solution?

CodePudding user response：

In my opinion, don't expose your internal obligations with external solutions like implementing APIs etc ...

Just share the database to be accessible for B. In this way, the server administration is the only security concern and nobody knows how you work. In addition, It's not important how you implement the user authentication for each one (whether Windows Authentication or JWT) and has an independent infrastructure.

CodePudding user response：

They are multiple solution to this one problem. It then end it really depends on your specific criteria.

You could go with:

• B (intranet) website, reaching into the database and creating user as needed.
• A (internet) website, having an API exposing the necessary endpoint to create user.
• A (internet) website, having data migration running every now and then to insert users.

But they all comes with there ups and downs, I'll try to break them down for you.

API solution

Ups:

• Single responsibility, you have only one piece of code touching this database which makes it easier to mitigate side effect
• it is "future proof" you could easily have more services using this api.

Downs:

• Attack surface increased, the API is on a public so subject to 3rd parties trying to play with it.
• Maintain API as the database model changes (one more piece to maintain)
• Not the fastest solution to implement.

Database direct access

Ups:

• Attack surface minimal.
• Very quick to develop

Downs:

• Database model has to be maintained twice
• migration deployment have to be coordinated, hard to maintain.
• Make the system more error prone.

Migration on release

Ups:

• Cheapest to develop
• Highest performance on inserts

Downs:

• Not flexible
• Very slow for user
• Many deployment
• Manual work (will be costly over time)

In my opinion I suggest you go for the API, secure the API access with OAuth mechanism. It OAuth is too time consuming to put in place. Maybe you can try some easier Auth protocols.