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.
Hello,
Why was it removed in this version? Actually i am not sure what was the internal gateway was doing on the previous version. was it only a gateway that is publishing the events from rabbitmq and do the communication between all micro-services?
Internal gateway was working as a service locator when microservices make synched (http) communication. It was not related with publishing events but only related with synched communication between microservices. I would suggest reading guide communication between microservices to learn more about it.
And if it was doing all the communication between all microservices before right now how it has been solved?
We were using dynamic proxy which resolves endpoint configurations in runtime. This required api-gateways to be dependent on other microservices' Http.Api layer. There were some problems related with design like having difficulty to change Ocelot to any other gateway (like envoy etc).
And i believe only "administration service" needs to make a call to "identity service", is there any other microservice making a call to other microservices?
Yes, specifically when you request User Permissions, AdministrationService makes a request to IdentityService. As default, there is no other synched inter-service communication.
But what i don't understand is why administrationservice needs to depend on 5 contractsmodule which are
Because of permissions. Each microservice has their own permissions but AdministrationService hosts the Permission Management module. Also for api-configuration see this issue.
ps: still on the doc it mentions about internal gateway which is not present probably it would be modified when the v5 is released.
Thanks, we'll update docs.