|
XML Web Services
Publishing and Security
Publishing a Web service means enabling a Web service user (consumer) to locate the
service description and instructing the consumer how they should interact with the
Web service. The process of locating and interrogating Web service description is
called the discovery process. There are two ways for the discovery of Web services, DISCO and UDDI.
DISCO
We use DISCO if the number of consumers using our service are relatively small. We
can directly give them the path of our Web Server and deploy the DISCO file on the
Web Server. When we build a Web service, Visual Studio automatically creates a DISCO
file. This file has an extension of .vsdisco and is stored
in the virtual directory of IIS along with the asmx file.
This DISCO file contains links to resources that describe the Web service.
Creating a Proxy using wsdl.exe
If we want consumers to program against our Web Service, we have to create a proxy
and an assembly. We can generate the proxy using the WebServiceUtil.exe command-line
tool with Visual Studio .NET command prompt. The wsdl.exe command line tool generates
a code file that represents the proxy to the remote Web service. We need to specify
the name of the proxy file to be generated and the URL where the WSDL can be obtained.
The command for that is:
wsdl.exe /l:VB /out:c:\convertproxy.vb http://localhost/ConvertUnits/service1.asmx?WSDL.
This line illustrates the use of wsdl tool to generate a proxy class for our ConvertUnits
Web service. The wsdl.exe utility generates C# (C-Sharp) code by default. If we want
our proxy written in VB .NET we can use the optional
/l:(language) as we did in the command line.
Creating a Proxy Using Visual Studio
We can also use Visual Studio to create the proxy class. We did that in the Sample
Service 2 section. Visual Studio automatically creates a Web service proxy classes
using the Add Web Reference feature. All we have to do is
provide the location of the WSDL document for the Web service and Visual Studio takes
care of the rest.
UDDI
The Universal Discovery, Description, and Integration (UDDI) project provides a global
directory of Web Services. UDDI enables consumers to search and locate Web services
if the consumer is not aware of the exact location of the service or the owner of
the service. UDDI is for Web services like Google is for Web pages. UDDI allows us
to easily find Web services based on a centralized and globally available registry
of businesses which are accessible over the Internet. If you have a Web service and
if you wish to publish it with UDDI then you need to visit the UDDI web site and register
your service there.
Finding Services
UDDI directory allows us to search for companies providing services. All we need to
do is visit the UDDI web site and search for the service we are interested in. Web
sites like Google, Amazon and EBay are also providing their services through their
web sites. You can visit their sites and download the SDK. The SDK provides all the
information you need to access their Web services along with the documentation that
helps you in it's implementation.
Security Configuration
We can us the Config.web file for all security related configuration
as all the information is in this file. We have the ability to configure three fundamental
functions for security: authentication, authorization, and impersonation. The Config.web
will have three additional sequences enclosed in the parent <security> tag.
Authentication, Authorization, Impersonation
All your Web clients communicate with your Web application through IIS. So you can
use IIS authentication (Basic, Digest, and NTLM/Kerberos) in addition to the ASP.NET
built-in authentication solutions. Some ASP .NET authentication providers are:
-Passport authentication, which is a centralized authentication
service provided by Microsoft.
-Cookie authentication, which issues a cookie to the request/response
that contains the credentials for reacquiring the identity.
-Windows authentication, which is used in conjunction with
IIS authentication.
IIS authentication methods assume that the user is already known to the server, while
ASP .NET methods don't. With Passport authentication your site has to support Microsoft
Passport credentials, and Cookie authentication assigns an identity to an “unknown
stranger” who complies with some rules. Once a client request is authenticated and
an identity is given, we have to determine whether this identity is allowed to have
access to the requested resource.
ASP .NET distinguishes two modes of authorization: file and URL.
File authorization is active when using Windows authentication. To determine if access
should be granted or not, a check against an Access Control List (ACL) is done. In
URL authorization, identities are mapped to pieces of the Uniform Resource Identifier
(URI) namespace to selectively allow access to parts of the namespace.
When using impersonation, IIS and Windows file access security play a role. IIS authenticates
the user using Basic, Digest, or Windows NTLM/Kerberos authentication. IIS then passes
a token to ASP .NET, the token is either authenticated or unauthenticated.
Code Access Security
Apart from the ASP .NET built-in security features, we can make use of code access
security feature of the .NET Framework. With code access security we can admit code
originating from one computer system to be executed safely on another system. Therefore
the code’s identity and origin has to be verified. To determine whether the code should
be authorized or not, the runtime’s security system walks the call stack, checking
for each caller whether access to a resource or performing an operation should be
allowed. In the .NET Framework you must specify the operations the code is allowed
to perform. This can be done, in the assembly of your Web application.
|