I finally get a chance to work on Silverlight after getting back from maternity leave then on with a new project.
I'm able to configure my WcfPortal as integrated windows authentication. There are several interesting findings with regard to current principal that CSLA handles for windows authentication scenario.
I found that the WindowsIdentity will work only when you turn off impersonation. This is very interesting choice for a default implementation where the majority apps with windows authentication does not turn on impersonation. With impersonation turn off, WindowsIdentity.GetCurrent() will return aspnet or network (service acct). I was trying to override/re-write the PopulateWindowsIdentity() but need to have the property info accessible on the overriding class.
By design, I see that WcfPortal shuttles back and forth the IPrincipal object. I'm not sure if this is necessary or even correct when using windows authentication. In my opinion, it should be one way, from server to silverlight client; so that silverlight client have a copy of authenticated principal but we should not set the ApplicationContext.User with IPrincipal from client side because the server has the original copy.
Thanks,
Ricky
OT: When posting, you need to separate tags with a ; or , - otherwise it is just one big (and useless) tag.
To your question:
Silverlight has no concept of Windows identity or Windows authentication. None. Nada. Zip. Zilch. Remember that Silverlight runs on the Mac and other platforms too - no Windows to be seen.
Of course people want to use Windows authn, so CSLA supports it in a way. The concept relies on the browser and ASP.NET to do the work - because they do understand Windows authn.
Arguably the SL client wouldn't need to pass this principal to the server each time, because the server should already know (via the browser login) which Windows user to impersonate on each call. But that'd preclude the use of an IAuthorizeDataPortal check to make sure the client principal still matches the server principal - something not everyone will do, but certainly a valid double-check against some mischief on the client.
Your IAuthorizeDataPortal code could easily set Csla.ApplicationContext.User to the real WindowsPrincipal too, if you'd prefer to be using that principal in the server-side code.
Rocky, Thanks for such a quick reply.
Yes, I do understand the creation of WindowsIdentity class so that CSLA can support windows authentication. I guess I'm ok the shuttles back and forth to make sure both uses CSLA's "WindowsIdentity" although to me is somewhat redundant. However the issue is when WindowsIdentity contains not the actual identity of the user but the identity of the service account (aspnet). This is happens when your app choose not to use Impersonate=True. see this to clarify: http://msdn.microsoft.com/en-us/library/aa302377.aspx
Implementing IAuthorizeDataPortal will not help here because by the time it calls Authorize method, the actual user identity which expected to be available in HttpContext.Current.User or Thread.CurrentPrincipal already being set (by WcfPortal.SetContext) with aspnet principal.
I think the main issue is that WindowsIdentity.PopulateWindowsIdentity() does not take into account when impersonate=True and I'm unable to override this method from my custom windows identity class. I also need to be able to access the property infos of these properties.
Making Csla.Server.Hosts.Silverlight.WcfPortal.SetContext as protected virtual can also give me the ability to stop principal being pass back to server, which not important but a nice ability to have.
Thanks,
Ricky
The CSLA WindowsIdentity class assumes you have impersonation turned on. I don't see how it could be of any use if you don't have impersonation turned on.
There are other identity types (membership, custom) that should be used if impersonation is turned off and you are trying to use other authentication models.
Changing the server-side SetContext() method doesn't help prevent the principal from flowing from client to server - it would just allow you to ignore it on the server. The more correct solution is to provide a way to tell CSLA to not pass the principal from the client, and to tell CSLA to not expect it on the server. That's what CslaAuthentication does in the .NET data portal, and there should probably be an equivalent for the SL data portal (added to wish list).
Without impersonation which is using the second scenario, I can use HttpContext.Current.User or Thread.CurrentPrincipal to get user name then use active directory to get the user's group.
| Web.config Settings | Variable Location | Resultant Identity |
|---|---|---|
| <identity impersonate="true"/> <authentication mode="Windows" /> |
HttpContext WindowsIdentity Thread |
Domain\UserName Domain\UserName Domain\UserName |
| <identity impersonate="false"/> <authentication mode="Windows" /> |
HttpContext WindowsIdentity Thread |
Domain\UserName MACHINE\ASPNET Domain\UserName |
What I'm saying is that the CSLA WindowsIdentity class is just a specialized custom principal designed to work with impersonation turned on. If you aren't using impersonation, don't use WindowsIdentity - use a custom identity of your own design.
And what I'm saying is that in your IAuthorizeDataPortal you can reset the server principal to whatever you'd like. Set Csla.ApplicationContext.User to HttpContext.Current.User if that's the correct value.
No problem, I'll implement from CustomPrincipal. I was just trying point out what I think is an issue with CSLA WindowsIdentity when impersonation is turned off. Which I think is dengerous, because if this object is used for authentication, the result is always IsAuthenticated = true since the windows identity is always grab the service account
Copyright (c) Marimer LLC