Friday, November 6, 2009
Building Secure Microsoft ASP.NET Applications: Authentication, Authorization, and Secure Communication
toc: "Building Secure Microsoft ASP.NET Applications: Authentication, Authorization, and Secure Communication"
WebClientProtocol.Credentials Property (System.Web.Services.Protocols)
Passing Credentials for Authentication to Web Services
Passing Credentials for Authentication to Web Services
When you call a Web service, you do so by using a Web service proxy; a local object that exposes the same set of methods as the target Web service.
You can generate a Web service proxy by using the Wsdl.exe command line utility. Alternatively, if you are using Visual Studio .NET you can generate the proxy by adding a Web reference to the project.
| Note | If the Web service for which you want to generate a proxy is configured to require client certificates, you must temporarily switch off that requirement while you add the reference, or an error occurs. After you add the reference, you must remember to reconfigure the service to require certificates. An alternate approach would be to keep an offline Web Services Description Language (WSDL) file available to consumer applications. You must remember to update this if your Web service interface changes. |
Specifying Client Credentials for Windows Authentication
If you are using Windows authentication , you must specify the credentials to be used for authentication using the Credentials property of the Web service proxy. If you do not explicitly set this property, the Web service is called without any credentials. If Windows authentication is required, this will result in an HTTP status 401, access denied response.
Using DefaultCredentials
Client credentials do not flow implicitly. The Web service consumer must set the credentials and authentication details on the proxy. To flow the security context of the client’s Windows security context (either from an impersonating thread token or process token) to a Web service you can set the Credentials property of the Web service proxy to CredentialCache.DefaultCredentials as shown below.
proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
Consider the following points before you use this approach:
§ This flows the client credentials only when you use NTLM, Kerberos, or Negotiate authentication.
§ If a client-side application (for example, a Windows Forms application) calls the Web service, the credentials are obtained from the user’s interactive logon session.
§ Server-side applications, such as ASP.NET Web applications, use the process identity, unless impersonation is configured in which case the impersonated caller’s identity is used.
Using Specific Credentials
To use a specific set of credentials for authentication when you call a Web service, use the following code.
CredentialCache cache = new CredentialCache();
cache.Add( new Uri(proxy.Url), // Web service URL
"Negotiate", // Kerberos or NTLM
new NetworkCredential("username", "password", "domainname") );proxy.Credentials = cache;
In the above example, the requested Negotiate authentication type results in either Kerberos or NTLM authentication.
Request a Specific Authentication Type
You should request a specific authentication type as illustrated above. Avoid direct use of the NetworkCredential class as shown in the following code.
proxy.Credentials = new NetworkCredential("username", "password", "domainname"); This should be avoided in production code because you have no control over the authentication mechanism used by the Web service and as a result you have no control over how the credentials are used.
For example, you may expect a Kerberos or NTLM authentication challenge from the server but instead you may receive a Basic challenge. In this case, the supplied user name and password will be sent to the server in clear text form.
Set the PreAuthenticate Property
The proxy’s PreAuthenticate property can be set to true or false. Set it to true to supply specific authentication credentials to cause a WWW-authenticate HTTP header to be passed with the Web request. This saves the Web server denying access on the request, and performing authentication on the subsequent retry request.
Using the ConnectionGroupName Property
Notice that the above code sets the ConnectionGroupName property of the Web service proxy. This is only required if the security context used to connect to the Web service varies from one request to the next as described below.
If you have an ASP.NET Web application that connects to a Web service and flows the security context of the original caller (by using DefaultCredentials or by setting explicit credentials, as shown above), you should set the ConnectionGroupName property of the Web service proxy within the Web application. This is to prevent a new, unauthenticated client from reusing an old, authenticated TCP connection to the Web service that is associated with a previous client’s authentication credentials. Connection reuse can occur as a result of HTTP KeepAlives and authentication persistence which is enabled for performance reasons within IIS.
Set the ConnectionGroupName property to an identifier (such as the caller’s user name) that distinguishes one caller from the next as shown in the previous code fragment.
| Note | If the original caller’s security context does not flow through the Web application and onto the Web service, and instead the Web application connects to the Web service using a fixed identity (such as the Web application’s ASP.NET process identity), you do not need to set the ConnectionGroupName property. In this scenario, the connection security context remains constant from one caller to the next. |
Calling Web Services from Non-Windows Clients
There are a number of authentication approaches that work for cross-browser scenarios. These include:
§ Certificate Authentication. Using cross platform X.509 certificates.
§ Basic Authentication. For an example of how to use Basic authentication against a custom data store (without requiring Active Directory), see http://www.rassoc.com/gregr/weblog/stories/2002/06/26/webServicesSecurityHttpBasicAuthenticationWithoutActiveDirectory.html.
§ GXA Message Level Approaches. Use the Web Services Development Toolkit to implement GXA (WS-Security) solutions.
§ Custom Approaches. For example, flow credentials in SOAP headers.
Proxy Server Authentication
Proxy server authentication is not supported by the Visual Studio .NET Add Web Reference dialog box (although it will be supported with the next version of Visual Studio .NET). As a result you might receive an HTTP status 407: “Proxy Authentication Required” response when you attempt to add a Web reference.
| Note | You may not see this error when you view the .asmx file from a browser, because the browser automatically sends credentials. |
To work around this issue, you can use the Wsdl.exe command line utility (instead of the Add Web Reference dialog) as shown below.
wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword> /
pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx
If you need to programmatically set the proxy server authentication information, use the following code.
YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials
Create List Item using SP List Web Service
//get data from form
string ContactName = textBox1.Text;
string PhoneNumber = textBox2.Text;
string Website = textBox3.Text;
string SecretIdentity = textBox4.Text;
// Declare and initialize a variable for the Lists Web Service.
sitesWebServiceLists.Lists listService = new sitesWebServiceLists.Lists();
/* Authenticate the current user by passing their default
credentials to the Web Service from the system credential cache.*/
listService.Credentials = System.Net.CredentialCache.DefaultCredentials;
/*Set the Url property of the service for the path to a subsite.*/
listService.Url = "http://brnet/it/playground/_vti_bin/Lists.asmx";
/*Get Name attribute values (GUIDs) for list and view. */
System.Xml.XmlNode ndListView = listService.GetListAndView("Test List", "");
string strListID = ndListView.ChildNodes[0].Attributes["Name"].Value;
string strViewID = ndListView.ChildNodes[1].Attributes["Name"].Value;
/*Create an XmlDocument object and construct a Batch element and its attributes. Note that an empty ViewName parameter causes the method to use the default view. */
System.Xml.XmlDocument doc = new System.Xml.XmlDocument();
System.Xml.XmlElement batchElement = doc.CreateElement("Batch");
batchElement.SetAttribute("OnError", "Continue");
batchElement.SetAttribute("ListVersion", "1");
batchElement.SetAttribute("ViewName", strViewID);
batchElement.InnerXml = "
//MessageBox.Show(sb_method);
/*Update list items. This example uses the list GUID, which is recommended, but the list display name will also work.*/
try
{
XmlNode ndReturn = listService.UpdateListItems(strListID, batchElement);
//show return from insert
MessageBox.Show(ndReturn.OuterXml);
//parse the xml to grab the id element needed
string ReturnID = "";
XmlNode resultNode = ndReturn.FirstChild;
foreach (XmlNode childNode in resultNode.ChildNodes)
{
foreach (XmlAttribute attrib in childNode.Attributes)
{
if (attrib.Name == "ows_ID")
{
ReturnID = attrib.Value.ToString();
}
}
}
//show return id
MessageBox.Show(ReturnID);
}
catch (SoapServerException ex)
{
MessageBox.Show(ex.Message);
}
Thursday, November 5, 2009
SharePoint Web Service
SOAP interfaces used in these services provide Microsoft .NET Framework developers with object models for creating solutions that work with Windows SharePoint Services remotely from a client or custom application. The interfaces are defined through the server-side object model of the Microsoft.SharePoint assembly, and their design is optimized to reduce the number of roundtrips transacted between client computer and server.
Most Web services provide their functionality through the /_vti_bin virtual directory, which maps to the \\Program Files\Common Files\Microsoft Shared\web Server extensions\12\ISAPI physical directory in the file system. The Administration Web service uses the /_vti_adm virtual directory, which maps to \12\ADMISAPI.
http://MyServer/[sites/][MySite/][MySubsite/]_vti_bin/Web_Service.asmx
Wednesday, November 4, 2009
Tuesday, November 3, 2009
WS-Security Authentication and Digital Signatures with Web Services Enhancements
The WSE Environment"
15 Seconds : Web Services Security in The .NET Framework
By Mansoor Ahmed Siddiqui"
Assembly reference in the User Cantrol
ISSUE:Load control template file /controltemplates/yourUserContolName.ascx failed: c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES\yourUserContolName.ascx.cs(11): error CS0246: The type or namespace name 'YourNameSpaceName' could not be found (are you missing a using directive or an assembly reference?)
RESOLUTION:
1. Have you deployed the UserCtrol-dll/3rd party dll/custom dll to the GAC, added it as a safe-control in the web.config file of the web appplication?
2. Does your ascx-control have the
<%@ Assembly Name="AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9999fa746b399999" %> declare it on top of the ascx page in the html code view.
