Windows Identity Foundation does set the Thread.CurrentPrincipal on the wcf side, which is overwriten by csla in case of another AuthenticationType then "Windows", but Federated Authentication (WIF) is not an WindowsIdentity so the Csla.Server.DataPortal SetContext Method overwrite the Thread.CurrentPrincipal
For the first MyIdentity.GetIdentity() this is an issue where i need to have access to the real identity set by WIF. I did write my own WcfPortal but i'm still using the server side of the dataportal, which i don't want to write myself.
I would like to request a modification in the SetContext method:
else if (ApplicationContext.AuthenticationType == "Federation")
{
if (ApplicationContext.User.Identity.AuthenticationType != "Federation")
throw new SecurityException("The AuthenticationType is Federation but the Identity is not!");
}
A screenshot of the ApplicationContext.User at the moment just before Csla overwrites it.
If you set the CslaAuthentication type to "Windows" then CSLA won't alter the value. There should not be a need for yet another setting - there are only two options: CSLA does set the value (Csla), or CSLA doesn't set the value (Windows).
Also, if you do want to do that extra check to verify the principal/identity, you can do that in the data portal's authorization provider (IAuthorizeDataPortal).
I (mis)used that IAuthorizeDataPortal interface on a class for one time initialization of dataportal code, the first time filling the static :)
Anyway the AuthenticationType isn't for veryifying the principal/identity, it's just that it isn't a WindowsIdentity so if i set the AuthenticationType to "Windows" the client code doesn't has the correct identity. Even worse, it has the windows identity which i don't want. I create a channel using the issued token to go to the server using an federation binding. There the Thread.CurrentPrincipal is filled by WIF that i need to use as identity on the server side.
I can get the ClaimsPrincipal with just one ClaimsIdentity (it can even be a collection or a own principal)
It can't be a WindowsIdentity and i don't want it to be a WindowsIdentity.
Well let's be very clear.
If the server's authentication type is Windows, that has no impact on the client at all. That just means that the server will not override whatever principal is on the server's thread - it lets Windows manage the principal.
If the client's authentication type is Windows, that doesn't mean the client uses the Windows principal, it just means that the data portal won't send the client principal through to the server.
As a result, if the server is set to Windows, the client must also be set to Windows so the principal doesn't flow from client to server.
All that is completely unrelated to the principal actually used by the client. Even if the authn type is Windows, the client can absolutely use a custom principal.
"Even if the authn type is Windows, the client can absolutely use a custom principal" is something i didn't knew. I though if it was set to Windows it would always be a WindowsIdentity. I'll check it out tomorrow at work, thanks.
I followed the same model as ASP.NET - which means that when you say "Windows" what you are really saying is "I will handle it myself, and if I choose to, I'll let Windows manage it for me".
It seems to work the way i want by setting the athentication type to "Windows"
Copyright (c) Marimer LLC