I am currently experiencing a problem getting windows authentication working with my CSLA 4 SL application. I have setup windows authentication the same way as the samples from the Silverlight videos. When I run the application from my development workstation, everything works fine. I then setup my development and test web servers using IIS 7.5. I worked through many issues getting impersonation to work (starting with just ASP.NET, then adding CSLA and SL). It all seems to work fine. I can open a browser on my development machine (or any other machine on that domain), go to the development or test web server and the authentication all works. Now here is where I encounter an issue: My testers log in to another domain. There is no trust relationship whatsoever between their domain and the domain where I host my CSLA SL app. I have given them all accounts on this new domain, and I let their browser prompt them for credentials to log in to the domain where they do their testing. In the ASP.NET world, everything works fine - ie. a call to System.Security.Principal.WindowsIdentity.GetCurrent() works - it shows their logged in user and groups. My next step was to add CSLA / SL to the mix. When I did this, I got some interesting results. The authentication wasn't working, so I started troubleshooting to see where the problem was. I ended up setting up remote debugging on my development web server so I could see what was going on. I found that everything on the server-side seems to be working just fine. I stepped through WindowsIdentity.PopulateWindowsIdentity() and I can see everything working fine. The server knows who they logged in as, what groups they are in, etc. The server seems to be doing the exact same thing in the success scenario (same domain) and the fail scenario (coming from another domain)
As it turns out, I am actually getting an exception on the client side. Here are the exception messages and stack traces that the client is throwing:
Debugging resource strings are unavailable. Often the key and arguments provide sufficient information to diagnose the problem. See http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.50524.0&File=mscorlib.dll&Key=TypeInitialization_Type at Csla.Silverlight.Security.WindowsIdentity.get_Name()
at Business.AppPrincipal.<>c__DisplayClass3.<Login>b__2(Object o, DataPortalResult`1 e)
at Csla.DataPortal`1.OnFetchCompleted(DataPortalResult`1 e)
at Csla.DataPortal`1.proxy_FetchCompleted(Object sender, DataPortalResult`1 e)
at Csla.DataPortalClient.WcfProxy`1.OnFetchCompleted(DataPortalResult`1 e)
at Csla.DataPortalClient.WcfProxy`1.proxy_FetchCompleted(Object sender, FetchCompletedEventArgs e)
There is also an InnerException of the following:
Can not register property Roles after containing type (WindowsIdentity) has been instantiated at Csla.Core.FieldManager.PropertyInfoManager.RegisterProperty[T](Type objectType, PropertyInfo`1 info)
at Csla.ReadOnlyBase`1.RegisterProperty[P](PropertyInfo`1 info)
Does anybody know what the issue here might be?
I think this is a bug in the WindowsIdentity class.
The old _forceInit trick doesn't work in SL4 in release mode, because the compiler is now smart enough to realize that the _forceInit field isn't used for anything meaningful - so they optimize it away (which is pretty impressive - but inconvenient).
The answer is that the PropertyInfo<T> fields need to be public. But in WindowsIdentity they aren't.
Can you try making them public and see if that helps. If so, I'll fix it in the core code for 4.0.2.
Ok, I was wondering what the _forceInit was for.
I made those PropertyInfo fields public and it now works. Thanks!
Good, thanks for the help!
I've put a bug into the tracker, so this fix should be in 4.0.2.
Copyright (c) Marimer LLC