|
|
| Overview |
The Omnify Web Services reside on a server running Internet Information Services (IIS) and the .NET Framework 2.0 (or above).
The server hosting the web services must be able to connect to the Omnify metadata and documents databases.
The Web Services contain main (landing) pages (.asmx file) and an accompanying code file (usually .cs file).
For example, the main Omnify Web services:
[install directory]\WebServices\OmnifyGeneralServices.asmx
[install directory]\App_Code\OmnifyGeneralServices.cs
Notes:
• The default install directory will be: C:\Inetpub\wwwroot\Omnify5.
• Most Omnify web services are written in C# (C Sharp).
When a Web Service is invoked the .NET Framework will read the date/time stamps of the code and configuration files to determine if a recompile is necessary.
Code changes can be applied to the supporting code files and the framework will dynamically create compiled Common Language Runtime (CLR) objects for each web service.
|
|
|
The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone.
XML (eXtensible Markup Language) - a standard data format that allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications. XML is used to tag the data being transferred to and from Web Services.
SOAP (Simple Object Access Protocol) – an XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including SMTP, MIME, and HTTP. SOAP is used to provide the "wrapper" or "envelope" when transferring data to and from web services.
WSDL (Web Services Description Language) - an XML-formatted language used to describe a Web service's capabilities as collections of communication endpoints capable of exchanging messages. WSDL is the language that UDDI uses.
UDDI (Universal Description, Discovery and Integration) - a Web-based distributed directory that enables businesses to list themselves on the Internet and discover each other.
|
|
|
.NET application security configuration and IIS security configuration are completely
independent and can be used independently or in conjunction with each other.
IIS maintains security related configuration settings in the IIS database. However,
.NET maintains security (and other) configuration settings in XML configuration
files (web.config).
The following figure illustrates the relationship between IIS and .NET.
.NET implements authentication using authentication providers, which are code modules
that verify credentials and implement other security functionality such as cookie
generation. .NET supports the following three authentication providers:
- Forms Authentication - Using this provider causes unauthenticated
requests to be redirected to a specified HTML form using client side redirection.
The user can then supply logon credentials, and post the form back to the server.
If the application authenticates the request (using application-specific logic),
.NET issues a cookie that contains the credentials or a key for reacquiring the
client identity.
- Passport Authentication - This is a centralized authentication
service provided by Microsoft that offers a single logon facility and membership
services for participating sites.
- Windows Authentication - This provider utilizes the authentication
capabilities of IIS. After IIS completes its authentication, .NET uses the authenticated
identity's token to authorize access.
<!-- web.config file -->
<authentication mode = "[Windows/Forms/Passport/None]">
</authentication>
Authentication Using Windows
Accounts Using Windows Authentication mode you can use accounts maintained by a
Windows domain controller or Active Directory. When authentication happens using
this method, .NET constructs and attaches a Windows Principal object to the application
context based on the authenticated user. As a result, the .NET thread can run as
the authenticated user and can obtain the user's group membership.
Impersonation and Delegation
With impersonation, .NET applications can optionally execute with the identity of
the client on whose behalf they're operating. Impersonation is usually performed
for resource access control.
If impersonation is enabled, .NET will receive the token to impersonate from IIS.
This is controlled by specifying a value in the application's Web.config file.
<identity impersonate="true"/>
To identify a specific account, use the name and password attributes:
<identity impersonate="true" userName="domain\user" password="passwd"/>
|
|
|
Many Web Service and application settings are controlled in a XML (web.config) file
contained in the main Omnify Web Services directory (e.g. C:\Inetpub\wwwroot\Omnify5\web.config).
Example Web.config file:
<?xml version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings>
<add name="OmnifyDatabase" connectionString="data
source=(local);Initial Catalog=Omnify;User ID=User;Password=Pwd;" providerName="System.Data.SqlClient"/>
<add name="OmnifyDocumentsDatabase" connectionString="data
source=(local);Initial Catalog=OmniDocs;User ID=User;Password=Pwd;" providerName="System.Data.SqlClient"/>
</connectionStrings>
<system.web>
<authentication mode="Windows"/>
<identity impersonate="true" userName="domain\user" password="passwd"/>
<httpRuntime executionTimeout="5000"/>
</system.web>
</configuration>
The key settings in this file are the "OmnifyDatabase" and "OmnifyDocumentsDatabase"
connection strings, and authentication and identity settings.
The web.config file can be edited directly with a text file editor or from the Properties dialog box in IIS.
|
|