During the first tests I always used the AddInMemoryClients configuration of IdentityServer4 as described in their documentation.
However I'm in the process of deploying it to our test environment and want to get rid off the configuration file so I've setup the Entity Framework integration.
Now all client ID's, client secrets, scopes, ... are persisted in the database in an encrypted way.
However, it's more difficult to add a new client.
What's the appropriate way to configure this?
Using Entity Framework migrations?
I know there's a UI available on top of IdentityServer4 but is that the only "easy" way?
Related
Is there a way to connect to a MongoDB Database from Codename One, and perform "CRUD" operations?
I'm new to Codename One database implementation.
You shouldn't expose your database to the mobile tier. It would let anyone who has access to your application manipulate/corrupt your data. It would mean transactions can fail because of bad network connectivity.
The way this should work is that you would create a server (e.g in Spring Boot or any other language). Expose a web service on said server and invoke that from the Codename One app. That Web Service will perform the CRUD operations.
I go into this extensively in my courses: https://debugagent.com/series/cn1
I use MySQL but all the same principals apply regardless of the technology.
I am developing a monolithic app using ABP IO. However, I want to apply as much as I can the ethic of microservices for easy migration to that latter architectural structure.
I have respected almost all constraints including Aggregation, DDD, and so on.
For the scenario synchronous communication between services, I have used the Client proxy for the C# as it has documented and it worked perfectly except on the side of permissions. I want configurable permission that could I use to differ between internal requests that are performed between modules (future microservices) and the public requests that come from outside.
Any suggestions??
Abp provides both dynamic proxy and static proxy (from v5.0).
Synched communication between microservices are done using Client Credentials flow. If you want to grant permission to a microservice you can either;
Add it in seeder method (like in this code sample).
Or if you are using commercial, you can use IdentityServer Management UI and add manage permissions:
You can also check synced communication between microservices guide for more information.
Is there a "best" way of achieving this?
Basically I want to leverage my company's Azure AD tenant to build a fully featured internal application. Using Microsoft Graph, I can retrieve users via their identifier guids, and use the identifiers as foreign keys for various tables in our on premises database, instead of having a dedicated User table, which would need to be populated and synced up with the AD. There are many other prospective uses for Graph, but leveraging users is the priority right now.
A large chunk of my application is built already. I am able to lock down my client app using the package react-aad-msal, requiring users to authenticate through single-sign-on. I have also successfully been able to pass that token back to the protected .NET Core API, accessing various endpoints as the authenticated user.
From here, I am not sure how I can develop the calls to Microsoft Graph. At which point should I make the connection? Should the client application connect to both the on-prem API, as well as Graph? Or should it only connect to the on-prem, which would then connect to Graph? Curious to know the pros and cons of either method.
I've also heard tell that Microsoft is working on their own package: #azure/msal-react, and that react-aad-msal should no longer be used (as it only supports msal 1.0 and not 2.0. I have no idea which version is better for my needs). While msal-react is still in development, apparently I should be using #azure/msal-browser. But I cannot find a good example of a react app using msal-browser to authenticate.
Here is a Sample on how to use MSAL with React to call Microsoft Graph.
The only different in your case will be that instead of calling Microsoft Graph, you will call your own API.
Bottomline is - there is no direct integration package yet for react. Which can also be read from the official statement on the msal-js repo:
After our current libraries are up to standards, we will begin
balancing new feature requests, with new platforms such as react and
node.js.
You can also use .net core instead. Please go through the sample here which can help.
I am new to web development, and have seen posts such as these . If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
You're probably going to get a bunch of conflicting opinions on this. My personal opinion is a web service in front of your database makes sense in some scenarios. Multiple applications connecting to the web service instead of directly to the db gives several advantages, security, caching, etc.
That being said, if this is just a single app then most of those advantages disappear and in fact just make things more complex for you. You're going to have to setup your web service for the db as well as your actual code.
If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
No, if Node.js is running on a server or in "serverless" containers (e.g. AWS Lambda) that is not a direct connection. That is a web service, and that's what you want.
A direct connection means the app connects to the database itself... but that requires embedding credentials in the app.
You do not want to embed anything in your app that you would not willingly hand over to an arbitrary user -- such as database credentials and API keys -- because you cannot trust that the app won't be reverse-engineered.
You should design the app in such a way that you would have no security concerns if the entire source code of the app were exposed, because knowing everything about the app's internals would give a malicious actor no valuable information. How? The code on the server side (e.g. in Node.js) should treat every request from the app as potentially suspicious, untrustworthy, etc., and validates every request to do anything.
This layer of separation is one of the strongest reasons why you never give the app direct access to the database. Code running in a trusted place -- your web server/API layer -- needs to vet every database interaction. This topology also decouples the app user from tying up resources on the database server when not actually interacting with the database, which is far less practical with a direct connection.
I'm developing an API using IdentityServer4 for authentication. I have already configured the stores to use EF Core and I'm using Asp.Net Identity too.
To improve the experience of the users, we want them to try our API on sandbox after signing up and offering them an autogenerated ClientId and ClientSecret. Once they want to go to production, we want to generate another ClientSecret for the production environment.
In other words, we want to reuse the ASP.NET Identity user and the IdentityServer client except for the secret.
We have different urls, databases, etc. for sandbox and production. Currently we are using two different IdentityServer servers and databases, but we are considering to share the same IdentityServer server and database for both environments.
Is this scenario supported in any way?
EDIT 1:
As stated on a comment to the response of travis.js, environments should be called live and sandbox instead of production and sandbox, as both environments are production ready to my clients.
EDIT 2:
The app embedding IdentityServer and Asp.Net Identity is the app that will manage the sign up, so the live and sandbox API will ask this app for authentication.
You'll run into problems trying to reuse the same the IdentityServer app/db under different urls. The hostname of your IdentityServer instance part of what make it unique and authoritative. One instance can't have two different authority names to my knowledge.
Sounds like a basic data migration issue, i.e., you just need to some of the sandbox config data moved up the production database.
Whatever app handles the user registration and "go live" features can do that work. It would just need access to both databases.