Activities of "mrbrl"

To be clear, is it a distributed cache problem, whereas we need to have a central cache location otherwise permission can be lost. Or is it a data protection concern, whereas the keys need to be cached on a shared drive or a caching provider like Redis?

please clarify.

Yes, we were hoping to possibly reusing ABP auth components instead of client authentication reimplementation. Thanks

The issue at hand is the database cannot be accessible by the blazor app - relying on API app on another server. Hence we cannot add IDS to the blazor web app as it would require database connectivity.

**Blazor WAF: **

• displays authentication UI (login/logout...)
• consumes Authentication API on IDS
• manages the authentication identifier
• has no database access
• can only consume APIs
• accessible to end-users

IDS:

• Exposes API's required for user authentication flow
• Support local users
• Supports LDAP
• has database connectivity
• not accessible to end-users

Thanks

Thanks for your reply. I have read the thread and glad to know support for IDS 4x will continue even as it hits end of support, as long as .net 7+ does not break it.

If Duende IDS 5+ integration is the same or very similar to that of IDS 4+, would it be a case to support the IDS5+ integration provided the road ahead is smooth and does not burn too much resources?

I read the chat ABP had with Duende, and understand the incompatibility that is largely due to business model differences. With that, if the integration effort is more or less the same as keeping IDS4 alive, without tapping on new features that Duende has in stock and provided the API remains largely the same for the ABP use cases, then why not?

Thanks - i did see the very informative thread about the migration after posting this. https://github.com/abpframework/abp/issues/11989 I understand that the platform should be able to plug any identity mechanism. that said - as IDS is already implemented albeit in a tightly coupled fashion that is slowly turning into a loose one, it may be sustainable to port the current IDS option to the new pluggable identity provider mechanism without breaking too much sweat, and leave the option to you grateful userbase to use it for their existing projects for instance - which would continue to benefit from ABP updates. New project may either use the soon to be the supported and free (for now) OpenIdDict - or IDS v4 (even after eos), or IDS 5+ (community or not), or minting custom providers (basic authentication :) )