So this brings me another question Isn't there anyway to get users without being coupled to identity service.
What makes you think you have to be coupled to identity service for identity user? I would suggest digging more on Domain Driven Design to see how to handle these kind of coupling (using data duplication etc).
For ex first thing that comes to my mind is to make identityservice not being a seperate microservice and include it in administration service? But probably it is the most used service? Why did you choose to make it a seperate service if it is gonna be coupled to administration service?
IdentityService, AdministrationService and SaasService are infrastructural services. Their dependency to each will not change when you develop your business services. Think of a case where you have to make a synced call (http request) to user list endpoint. Wouldn't it make more sense to be dependent on to only IdentityService instead of a merged AdministrationService where its main functionality is managing existing modules?
or how do i need to do decisions when i am seperating monolith project to microservices? Is there any guide or docs or any book to read to learn more about it?
Deciding how to seperate monolith into microservices is a very popular question that you can find many related answers to that from google. I mostly favor the answer: experience. Hardest part of DDD is deciding bounded contexts (henceforth, dividing monolith context into bounded contexts) which requires domain experts or high knowledge about DDD and experience.
There is a great free-ebook Domain Driven Design with the ABP Framework i would suggest. And also Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.
Well, IdentityServer is an openid provider, how will it happen than?
You want identityserver to call an endpoint to check if the client exists and has the required scopes etc for the authentication? What will authorize that endpoint? It seems like a loop to try to authenticate the authenticator.
I can't think any other solution then to keep in-memory configuration which is a very limited demo functionality.
And this is not really related with abp. Maybe someone else had a same issue and found a solution in identityserver4 github repo or stackoverflow?
We don't have any support or infrastructure for entity property level (row level) authorization. This seems a general question about query interacted authorization. Maybe stackoverflow can help better?
Thanks for your suggestion. We use this naming pattern not only in Role but also in other CRUD entities.
You can always override the localization. Please check localization docs for more.
Closing the issue, feel free to re-open if it occurs again.
If you want to implement passwordless authentication to identityserver, you can check:
Do you mean authorization based on entity properties or do I understand wrong?
In 3 tier architecture, user are not allow redirect to indentity server login page. In this case, anyway to configure only allow user login via .web instead of redirect to identity server login page ?
You can use Resource Owner Password flow which is not suggested for MVC applications and it may cause security issues. You can also use non-tiered template where identityserver, host and web applications are hosted in the same webserver.
We would love to help if you can provide us the related application logs. The screenshot you have sent tells us that it is an HTTP 403 error but the logs you have shared doesn't involve anything about it.
Also if you are having problems in production, please paste related production logs.
So to summarize, you removed internal gateway because there was only one synched (http) communication which is between administration service and identity service.
Not really. We didn't want gateways to be dependent on Http.Api layers of microservices so that developers can easily switch to an other gateway stack (like envoy etc).
All the permissions are defined in application contracts, so this brings us to the conclusion, whatever microservice that implements permission manager module needs to define every microservice application contracts module, so permission manager can do crud operations on the permissions?
Pretty much, yes.
Your sample about synched communication between porudct service and saas service seems right. Also you can check this answer about Client Credential Flow.
So as i understand identityclients options are configured in AbpHttpClientIdentityModelWebModule but in the docs it has been used AbpHttpClientIdentityModelModule can you clarify the difference between 2?
AbpHttpClientIdentityModelWebModule is used for UI involved flows when http context accessor is used while AbpHttpClientIdentityModelModule doesn't use the http context. AbpHttpClientIdentityModelWebModule already implements AbpHttpClientIdentityModelModule.
Also if i am planning lots of communications between different microservices internally isn't the internal gateway with ocelot is better approach maybe it is not very efficient if one microservice needs to call another but overall can we say that if we have many communcations between our microservices isn't it better to configure an internal gateway instead of configuring all the microservices one by one? What i am asking is are you planning to replace back internal gateway with another solution than ocelot or is it gonna be gone for good?
Surely. If you want to use dynamic proxy and keep using ocelot you can use an internal gateway and set
"RemoteServices": {
"Default": {
"BaseUrl": "https://localhost:44388/" // Internal Gateway url
}
}
in other microservices.
However, keep in mind that you are tightly coupling the microservices by making synched inter-communication. If you have lots of communications between different microservices, I would suggest differentiating them and decide which ones should be synched communication (with http requests) and which ones can be async over eventbus.