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.
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 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.
In a legacy Windows Forms application, users are now identified by an LDAP query. In essence, they scan their badge (barcode) and the application runs an LDAP query to get user attributes.
I know, from a security perspective, this is bad, but usability is more important than security in this case (we're talking about machine operators and they just need to sign-in / sign-off).
Now, we would like to move to a web-based architecture and the simplest thing would be to run the LDAP queries from the back-end to achieve the same.
However, I was wondering if we could switch to a more secure solution using ADFS and RFID/NFC badges, but I can't find any existing implementation. (I'm not looking for 2FA).
So, I'm trying SO, knowing this question can result in opinionated answers: if anyone has experience with a similar use-case, please stand up.
ADFS doesn't do this OOTB.
You could write a custom authentication feature or use the MFA server.
I see you don't want MFA but if you look at the screenshot, it does more than MFA.
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
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 last year.
Improve this question
Cheers,
We started implementing biometrics authentication in our web system and came to a doubt. We're going to use a third-party solution for performing it which is going to be called via a web service.
There are going to be four kinds of authentication:
Regular one: username/password
Challenge
Fingerprint
Cellphone
All users will be authenticated using 1. Optionally, some of them may also require 2, 3 or 4. What would be a good way of verifying which authentication type is required for a specific user?
This is something new for me. Initially, I thought about passing the username from the login page to a web service, which would query the database to check which authentication type is required for this user. Then, depending on the result, the second authentication form would be shown on the screen. Obviously, some extra check would be performed after the user hit the Submit button.
Am I on the right path, or there are better solutions for this?
Thanks,
I guess that would work. Maybe it is an option to do some sort of query in the background (AJAX?) when the username is filled in, so you can dynamically add extra inputs to your login form.
However, this has one potential issue: everybody that knows someone 's username can find out what authentication is required. If that is not wat you want, maybe just ask for a username + password to login to a reduced privelege mode. Then, as you suggested in your question, this reduced privelege mode may require extra credentials to continue to the more secure environment.
You could even make it so the reduced privelege mode will grant access to some of the features, while others require extra authentication (for example: posting a mesage would require basic auth, changing passwords might require all four).