Problems in WebServicesProxy and Windows Authentication

Problems in WebServicesProxy and Windows Authentication

Old forum URL: forums.lhotka.net/forums/t/4054.aspx


HummerHead posted on Monday, December 17, 2007

Please advice how to make Windows authentication actually working when data access is managed by a Web Service. Client is either WinForm or WebForm application, .NET 2.0. CSLA 2.1.4.0 (3.0.3 seems to have same problem), server OS is Win2003, client OS is either Windows 2000 or 2003.

We are trying to setup security by allowing only designated users get access to the system. So the dataportal hosting web service's web.config contains:

<system.web>
   <
authentication mode="Windows"/>
   <
authorization>
      <
allow users="user1"/>
      <allow users="user2"/>
      <deny users="*"/>
   </
authorization>

Client apps contain:

<appSettings>
   
<add key="CslaAuthentication" value="Windows"/>
   <
add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WebServicesProxy, Csla, Version=2.1.4.0, Culture=Neutral,PublicKeyToken=93be5fdc093e4c30"/> 
   <
add key="CslaDataPortalUrl" value="http://servername/PortalApp/CSLAPortal.asmx"/>

Now if IIS enables Anonymous access to PortalApp, everything works simply because anyone can use the portal, but there is no security. Once Anonymous access is disabled, Integrated Windows authentication is enabled, error 401 gets returned, because client doesn't supply user credentials in WS calls according to server logs. The problem is easily fixable by telling CSLA to use Default Credentials somewhere inside client's CSLA code like:

public class WebServicesProxy : DataPortalClient.IDataPortalProxy {
   
private WebServiceHost.WebServicePortal GetPortal() {
      WebServiceHost.
WebServicePortal wsvc = new WebServiceHost.WebServicePortal();
      wsvc.Url =
ApplicationContext.DataPortalUrl.ToString();
      
wsvc.UseDefaultCredentials = true;
      
return wsvc;
}

After that IIS can authenticate the user. While this fix be a bad way, I don't see how to make it working else. In the book we read in chapter 8:

Custom Authentication
Applications may use either Windows integrated (AD) or custom authentication. Using Windows integrated security requires no extra coding in the business layer, and the only code required in the UI is to tell .NET to use Windows authentication, by calling AppDomain.CurrentDomain.SetPrincipalPolicy() in Windows Forms, or in the web.config file for Web Forms or Web Services.

May be this server side is meant. AppDomain.CurrentDomain.SetPrincipalPolicy() gets executed in Server\DataPortal and never on client. Forcing its execution on client, did'nt help. 401.
BTW it isn't clear for me what the phrase "by calling ...SetPrincipalPolicy() ... in the web.config file for Web Forms or Web Services" means.

Is that a bug in CSLA?

Thanks an advance,
Andrew.

RockfordLhotka replied on Tuesday, December 18, 2007

You will probably need to create a custom data portal proxy class in your project. Take a copy of the web service proxy class from CSLA, put it in your project, then add the code to force the passing of Windows credentials from the client to the server.

The web service proxy was originally created to illustrate how far you could go with data portal channels - even using a limited technology like web services.

(That, and because we had a client who made a corporate policy that "only web service traffic will go across our network", but they still wanted to build powerful client/server apps...)

Of all the data portal channels, this is my least recommended channel. It works, but if you look at what it is doing, it is manually recreating Remoting through SOAP. The result is functional, but not as efficient as Remoting, and it offers no benefits over Remoting. In other words, it is inferior to Remoting.

My goal in including this web service proxy in the book/framework was to provide a starting point for people who (for whatever reason) were forced to use web services instead of Remoting or WCF. For example, some people use WSE, and so can take my code as a start point and alter it to work with the way they are using WSE. Then there is some value over Remoting, though today I'd recommend skipping all that pain and just going to WCF.

HummerHead replied on Tuesday, December 18, 2007

Thank you for the response!

We'd go with WCF if we could. We may reconsider remoting.

At least CSLA is flexible enough to accept customization, which worked immediately for my case.

Regards, Andrew.

Copyright (c) Marimer LLC