Todd, Matt and I have been working with SharePoint and Windows Phone 7 a lot lately. There are a lot of great scenarios for connecting Windows Phone 7 to your SharePoint farm. The phone platform provides a great reach scenario for many SharePoint applications. Unfortunately Windows Phone 7 does not support NTLM in custom development scenario and that is the most common authentication scenario we run into with SharePoint farms.
Not to worry, we still can connect to SharePoint using Windows Phone 7 without NTLM support from the phone platform. The first scenario is Basic Authentication to a Universal Access Gateway server (UAG). Todd and Matt authored a whitepaper (Building Windows Phone 7 applications with SharePoint 2010 Products and Unified Access Gateway (UAG) ) that covers integrating SharePoint social with Windows Phone 7 using UAG . UAG allows the phone to connect using Basic Authentication to UAG which then communicates with the SharePoint Web Application via NTLM. While the UAG solution sounds great, it is an expensive solution that requires a solid understanding of how to setup UAG. If you already have UAG installed or are thinking of using UAG for more than phone access then this is probably the best way to go for authenticated phone integration.
If not UAG then what? Forms Based Authentication is another option. We have used FBA in the SharePoint 2010 and Windows Phone Training Course as well a few applications we have worked on. This requires a Claims mode SharePoint Web application that has been set up to use FBA. FBA is fairly common in an extranet or partnerNet scenario.
If the main users are using Windows accounts and the Web Application is running in NTLM or Kerberos mode you have two hurdles to jump.
- Create an FBA entry point.
- Create FBA accounts for your Windows account users.
Note: Creating FBA accounts for the Windows user accounts results in the users having 2 distinct SharePoint users to manage. You cannot resolve an FBA user to a Windows user.
There is one other scenario which will work for users with Windows accounts: Basic Authentication without UAG. UAG is not required for Basic Authentication with SharePoint. Basic Authentication passes the user’s login and password to the server in the request. SharePoint supports Basic Authentication and we can use code to pass user credentials to a SharePoint Web service. This allows us to expose our SharePoint site to the phone platform without requiring FBA and potentially duplicate user accounts. There are a few tricks to passing user credentials from the phone platform to the server via the SharePoint remote APIs which I will show below. One note you should only do this over SSL as the user name and password are sent in the clear to the server.
Here is how you can access your site from WP7 using Basic Auth:
First enable Basic authentication for your Web application. This is done using Central Administration web site. Open Central Administration and click on Manage web application link. Select the appropriate web application and then click the Authentication Provider Ribbon button. Select the zone you want to work with, for example Default. Now locate the IIS Authentication Settings section and enable Basic Authentication. Click Save to save the settings. Your web application is now set to use Basic Authentication.
Now that the Web application is set to use Basic authentication you can connect to it using WinPhone7 (assuming your site is correctly configured for access from the emulator or the phone). I will focus on calling a Web Service using basic authentication.
There are three different methods to authenticate using Basic Authentication to a Web Service:
1. Web Service Proxy – setting credentials
2. Hand-coded SOAP – setting the Authorization Header
3. Web Service Proxy – setting the Authorization Header.
Method 1 is how I would normally pass credentials to a Web Service. In this method I would include a reference to the Web Service and let Visual Studio create the proxy class. Next I would create a new Windows credential and associate it with the Credential property of the proxy class. This method is simple and quick – except I have not been able to authenticate using this method. I am not sure why but it seems the credentials are not passed correctly.
Method 2 is to create the SOAP request without using a proxy. This involves a lot more code but allows you access to the request to add the Authorization header. In this method you add the authentication header to the request. You will need to pass in a Bin64 encyrypted version of the user’s id and password (more coverage to follow). Hand coding SOAP requests are a little messy but it does work.
Finally Method 3 is the hybrid of method 1 and 2. It uses the Web Service proxy and allows you to add the Authorization header to the underlying request object. Todd and Matt used this technique in the SharePoint social with Windows Phone 7 using UAG whitepaper to use Basic Authentication against UAG before UAG accessed SharePoint using NTLM. In this scenario we are removing the UAG server.
In order to use the proxy objects created by Visual Studio and authrozie using Basic Authentication requires you to work with the OperationContextScope and HttpRequestMessageProperty objects. Using these objects you can gain access to the WCF channel to add the Authorization header to the underlying request.
Here is the code you will need to create the Authorization header on the SharePoint Lists.asmx web service:
BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress endpoint = new EndpointAddress(“http://[servername]_vti_bin/lists.asmx”);
ListsSoapClient client = new ListsSoapClient(binding, endpoint);
client.GetListItemsCompleted += new EventHandler<GetListItemsCompletedEventArgs>(client_GetListItemsCompleted);
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
HttpRequestMessageProperty reqMessage = new HttpRequestMessageProperty();
reqMessage.Headers[System.Net.HttpRequestHeader.Authorization] = “Basic ” + Convert.ToBase64String(Encoding.UTF8.GetBytes (“MangoDarrin” + “:” + “<Add Pwd>”));
OperationContext.Current.OutgoingMessageProperties.Add(HttpRequestMessageProperty.Name, reqMessage);
client.GetListItemsAsync(<List Name>, null, null, null, null, null, null);
}
Notice in this example the user id and the password are encode to a byte array and then finally converted to Base64. The results of the above code is the setting the Authorization header on the underlying request. Effectively this code is the long way around setting a header for the request but it gets the job done.
I should say that I have not used the above code over SSL yet. Most of the SharePoint services I use regular use self-signed certs. The current phone platform does not provide a way to load a self-signed cert. There are ways of adding a self-signed cert but that will be a later post.
Since we don’t have support Windows Authentication using NTLM in the phone platform yet we need to make do with what we have. That boils down to FBA when we have FBA users, UAG to integrate with NTLM or simply adding Basic Authentication to our existing Web application. In many scenarios’ Basic Authentication over SSL will support our authentication needs.