Modernize the data portal authn model

[rockfordlhotka]

The historic data portal authn mode has been to flow the client-side principal/identity objects to the server with each data portal request. While this is easy and convenient, it is not inherently secure.

A better approach is to be secure by default, so using the "Windows" authn mode where every data portal request must be authenticated on the server.

[TheCakeMonster]

I think we would be better to add a Boolean flag to one of our configuration classes which is used to decide whether to flow context from client to server - and then have the new flag defaulted so that the flow is disabled by default. We would then add a new extension method to the fluent configuration to allow developers to reenable it, if they so choose. The new method would be discoverable by using a suitably descriptive name, such as EnableUserContextFlowToServer().

Use of a Boolean is better than the current string-based mechanism partially because it is independent of authentication type. By that, I mean that if someone sets a custom authentication type, the flowing of context changes, and they may not have expected or intended that. Furthermore, it moves away from us relying on a string comparison - a case-sensitive comparison. With the current code, a typo or copy/paste error can disable the protection intended by the "Windows" string value.

[rockfordlhotka]

From @TheCakeMonster

I am very comfortable with the code change to the data portal. The bit that it would be valuable for us to debate is the change to the application context managers in Csla.Windows and Csla.Xaml. Is this change in behaviour as intended? We no longer look for the authentication type to be set to "Windows". This comes with the benefit that it might work a bit more naturally out of the box, but do we lose any flexibility this way?

I am also comfortable with the changes you've made.

Regarding the Windows/XAML environments, I think we can update their configuration as well, to better match the config model and how things really work.

Specifically, I'm thinking that the UseXaml() config method (and the corresponding WinForms one) can accept options that include a DefaultToWindowsIdentity flag. When set true, the default user identity would come from WindowsIdentity, otherwise we'd use the same behavior as for all other environments.

  services.UseCsla(o=>o
    .UseXaml(xo=>xo.DefaultToWindowsIdentity(true)));

Obviously for XAML that flag will only be honored on a Windows device (WPF, and I suppose MAUI?). For Windows Forms it always makes sense.

[TheCakeMonster]

OK, interesting. I can't quite picture that at the moment. Where would that apply; is that is mostly to do with the change to the ApplicationContextManager classes in Csla.Windows and Csla.Xaml?

Does it makes sense to merge the PR I have submitted and then for you to add that as a separate change, on top of this?

[rockfordlhotka]

Yes, it applies to those specific ApplicationContextManager classes. I'm probably overthinking it, so I think accepting your PR and leaving it alone is the way to go.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.