Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have integrated my asp.net core app with identityserver4 and succeeded to authenticate and authorize users, my architecture now is as follow:
I have a separate server for identityserver4 with a separate database for all user tables(asp.net core identity tables).
I have an MVC client with a separate database with table called Accounts which hold the userid from identityserver4
I need to do user management stuff I am stuck with two scenarios
1- Create, delete, update accounts from the client MVC app and create an API at the identityserver to reflect that at the table users
2- Allow the client MVC app to access the identity database with identityserver4 and directly do user management
So, what is the best architecture, one shared database for the identityserver4 and the MVC client or or a separate database for identityserver4 and another database for the MVC client?
I would prefer the first option. But it depends on the context and requirements. If you are creating a green-field project that might be larger after some time (which would contain more services), then I recommend you to try microservice architecture.
Microservices often scale much better than monolithic apps but the architecture and overall tech stack might be more complicated. The key point is that they are independent - so they share nothing, database not at all. It comes with other problems, for example synchronizing the databases. It is well described in the free eBook: NET Microservices: Architecture for Containerized .NET Applications (here or here, but you should read also other pages).
If you plan to create just small services that might be part of a non-microservice ecosystem, the 2. choice may be better.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 days ago.
Improve this question
Me and my team are going to develop a trading application.
We are discussing about authentication service.
We've decided to use the Duende's Identity Server instead of Azure AD.
But a team member suggested to use Azure AD to manage all users.
His point is: Instead of coding every line of code to manage the users, we will use the Azure AD. For that we will not need to spend too much time for coding user manager, all the email can be integrate with SendGrid (welcome email, password restore etc.). We have a lot of things to do (Portfolio, MarketData, Payment, Trading etc.), spend too much time for develop the user manager is not a wise choice, just leave that to Azure AD, we will code the function only.
He really made his point, so now I'm investigating a question: Is it worth do to do that?
I also did some research with ChatGPT to gather information (I only have about 2 weeks knowledge with Duende's Identity Server. With Azure AD, I only know what it can do, but no reality experience yet.)
Duende's Identity Server vs Azure AD
Integrate Duende's Identity Server and Azure AD
Duende does have a user management system.
Usually, you integrate identityserver and Azure AD via federation but that's just for authentication.
They use two different DB.
identityserver can use other identity repositories via extension points so you could use Graph API to access Azure AD but that would be a strange way to do it.
If you are going to use Azure AD for user management, just use it for everything. Or use AdminUI and go with Duende.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 days ago.
Improve this question
I am currently in the process of designing a network of servers and databases for a project.
One key aspect of this project is the implementation of a central authentication server which will utilize session IDs to track sessions. These session IDs will be stored in cookies and sent back to users upon successful login.
Note: I understand that nextjs can work as both a front end and a back end. For reasons I will not get into here, nextjs is being used as a front end, and a separate central authentication server is being used for authentication. There are other servers/databases that will store data that users can access if they have proper permissions levels.
In step 1, I have no questions.
In steps 2 and 3, when the cookie is sent back to the nextjs server, what is the best practice for nextjs to determine the authorization level of the user?
I believe it's important that...
- Nextjs should know what navigation tabs to show, etc., when it renders the page for the user.
- Nextjs should also know what pages the user is allowed to visit. If the user is asking for a server-side rendered page that it isn't allowed to visit, it should be blocked
Possible option: Here, do I include some sort of JWT with authorization levels? It is my understanding that nextjs may be able to read these JWT authorization levels in middleware, then deny certain page requests that the user has by reading the JWT each time they request a page. Perhaps, even without middleware, functions could be used within the pages that would run server-sided, checking the JWT permission levels. Note that, in order for the nextjs server to know what the authentication levels are for the user, the tokens would have to be created in the central auth server, and then sent to the nextjs server.
Side thought: It seems that if I were to implement a function that checks the authorization level on a SPA, there would always be a way that a hacker could at least visit the blank page, correct? In other words, the only way to truly hide pages and navigation tabs from a hacker would be by somehow checking authorization levels server side (server-sided rendering), and then sending back a rendering of the page that only shows items related to the exact permissions of the user?
Overall, I would greatly appreciate any advice or insight on the best methods for authorizing users and limiting access to pages and tabs based on permission levels. While cookies will be used to store the session id and determine the data that users can receive when making API calls, additional measures such as JWT may be necessary for authorizing users to view specific pages. Is it common to utilize a combination of session/cookies and JWT for this purpose? What are the recommended best practices in this scenario?
Thank you for your assistance.
Forgive me if there's already been a very similar post to this - I searched and did find "related" threads, but none that hit home, or it was targeting a different version of asp.net or asp.net core. I just need some advice and pointing in the right direction.
My healthcare organization already has/uses a few OLTP systems for capturing patient data. I'm developing an Intranet that will consume the data from the various systems and present summaries/aggregations of that data for stakeholders. I'm developing the Intranet with ASP.Net Core MVC 2.0.
Being that the data is patient healthcare information, both Authentication AND Authorization are extremely critical.
For the intranet Auth, there's no point in reinventing the wheel - don't want to create the Auth layer from scratch. The existing OLTP systems already have very robust Auth layers, with detailed User Info, Roles and Profiles. Through Data Integration, I can get that User Auth data form the existing systems, store it in SQL Server tables, and then leverage it in the Intranet.
The question is, what's the best approach to accomplish that in a concrete manner.
Again, I already have all the necessary roles and profiles, I just need to be able to reference them in MVC to be able to:
Accurately authenticate users.
Would this be best accomplished using EF in an AccountController?
Appropriately conduct Authorization (show/hide/prevent menu options, access links, pages, etc.).
Would it be possible, or is it bad practice, to map the existing user roles and profiles to Claims in MVC via a proprietary sql server bridge table?
Again, please know that I'm using ASP.Net Core 2.0... so please don't provide any example code snippets in 1.0. (The Auth architecture drastically changed between 1.x and 2).
Thank you all for your consideration and time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are using Worklight 6.1 for our app. I want the app to remember the user id (with no limitation on the duration & it should be accurate & reliable).I want to use JSONStore API for this purpose.
In our app, after we gather the user credentials, we are sending them
to an adaptor function, where we are invoking some java classes to
validate the credentials aginst IBM bluepages & also against dbs
I have two questions:
1) When i ensure that user has been authenticated successfully for the first time, I will open a JSON store & keep the userid to the local storage, If I choose to encrypt it , which password I need to supply to make it encrypted ?
2) When the user tries to access the app from the same mobile device, the server should send a login form by pre populating the user id, how do I do this?
Thanks..
Encrypted Offline Cache is deprecated, so you might as well use JSONStore.
In MobileFirst Platform 6.3 ("Worklight"), there is a tutorial that accomplishes exactly your scenario. You should read it and try to implement it in 6.1; depending on JSONStore's featureset in 6.1, you might be able to. You'll need to try.
Here it is: Offline Authentication
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I´m currently designing a mobile application, and I´m having some concerns about securing the backend which runs the services for it to run.
My current planning is, using SSL and a basic workflow like this:
The generated token expires, because it assures that if someone physically access the phone/device, he cant be in control of the user account for too long, but, at the same time, I don't know what duration is appropriated for it, as I don't want to keep asking for credentials every day.
My questions are:
Is this a good aproach? Would you add something else to it?
Whats the ideal duration of tokens when working on mobile apps?
First thing first, you should encrypt session key when you store it on device. For example, use shared preferences with encrypt option. Further info : Android SharedPreference security
Second, you may want to implement "SSL pinning" mechanism. Which means that verify SSL certificates at client side. You must be sure about that received certificate is belongs to your backend or not. So you can protect your backend URLs and parameters with that way. Further info : https://www.infinum.co/the-capsized-eight/articles/securing-mobile-banking-on-android-with-ssl-certificate-pinning or http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
Third, your design is good. But be sure about your session key generation mechanism is not vulnerability against "Session Prediction" attacks. https://www.owasp.org/index.php/Session_Prediction