April 21, 2006

In 2006, one of the main difficulties in the BPM (Business Process Management) of IT is to bring B2B vendors, partners and customers to the same platform and rapidly address their specific needs and concerns.

Surprisingly, in less than ten short years we witnessed immense progress in innovative technologies, especially in the B2B segment. These technologies are changing the landscape of communications that made the world much smaller.

Thanks to modern Internet technologies and standards, companies and partners can now enable unified collaboration platforms viable across the majority of business communities.

Such platforms not only help better integrate BPM, but also better optimize it by consolidating the solutions where several heterogeneous applications integrate and interoperate with service oriented architecture foundation.

In this premise, the underlying open infrastructure not only hosts the common services but also protects on-going investments that inherit extensibility, reliability, availability, scalability, and manageability.

However, the world isn't perfect. So to support such automation without glitches will take some time.

As we open the infrastructure for flexible and ease-of-use services, there are challenges to address on-going threats. For example, we see hundreds of virus-infected documents, thousands of "Denial of Service" attacks, and billions of spam messages that result in depleting IT resources, increased down-time, and a decrease in productivity that ultimately impacts the operating costs and quality of services.

Sometimes, poor technical design will make "sensitive and confidential information" visible everywhere and accessible easily. Employee privacy is at risk as unencrypted information flows within and outside the enterprise.

We also see disturbing cases of corporate abuse that lead to "Regulatory Compliance (RC)" measures that are now taking a toll in IT costs (though RC has long term benefits). To minimize or to eliminate such risks, each solution must embrace measures on security and regulatory compliance at the architecture design level. This brings greater discipline to prevent abuses of the openness of the infrastructure. Besides, enterprise solutions will not survive without a clear support and maintenance strategy.

People, processes and products certainly are the ingredients to provide robust, reliable and resilient infrastructure. However, good service level agreements, better training to users and best practices keep the infrastructure healthier.

In this article, I will describe a shared infrastructure model based on service-oriented-architecture (SOA) that accommodates virtually any business solution. The framework can also be adapted for the upcoming Software-as-a-Service (SaaS) model where the multi-tenancy is the main theme. A simple methodology is applied for the architecture design and delivery processes. At the end, as an example, the design of the infrastructure for Virtual Collaboration is discussed by selecting a vendor product.

Solutions Architecture Bricks
Often the term "solution" is used in the context of development of an application. However, for the business community, it is the end-to-end offering to meet or exceed a set of use cases (aka requirements). In integration world, the solution comprises of a set of vendor products with some degree of customization and minimum application development as glue-ware. In today's datacenter approach, the challenge to vendors is to integrate their products on the shared infrastructure. Besides, customers are looking for applications based on open standards that integrate, interoperate and coexist seamlessly.

Enterprise Solutions Architecture framework defines a shared infrastructure consisting of platforms (Servers, Network, Application, Database, and Storage), transport protocols, common services, standards, policies, best practices and support strategies wrapped with security and compliance essentials.

Platforms
The platforms can be broadly categorized to a) Server platforms, b) Network platforms, c) Database platform d) Application platforms, and e) Storage platforms (SNADS). The market is truly open and a wide choice is at our door steps.

The server platforms (hardware and operating systems) are now more open and are becoming more powerful, resilient and inexpensive day by day. There is a wide variety of vendors in the market place to offer price/performance boxes. Today, the most popular server hardware platforms are based on Intel, AMD, IBM, and SUN processor technologies running operating systems such as Windows, Linux and UNIX variants, packed with wonderful tool set. Besides, with the 64-bit and multi-core processor evolution, the power of computing is at the door-steps for a fractional cost.

The network platforms that comprise of switches, routers, and firewalls etc are now provided by wide variety of vendors such as Cisco, Juniper, F5 and others. These vendors now provide edge and core appliances that cover perimeter defensive, load-balancing, ssl-off-loading, application acceleration etc. These network appliances are mostly based on linux kernel.

There are now a wide variety of databases such Oracle, DB2, SQL Server, MySQL etc for the platform of choice. SAN has emerged as highly resilient storage architecture. The storage vendors such as EMC, Hitachi, HP, and IBM and the SAN fabric vendors such as Brocade, EMC, McDATA et al provide the most robust storage platform with reasonable costs. These storage appliances are mostly based on linux kernel.

The emerging application platforms that enable managed code not only enhance reusability, portability and troubleshooting, but also tremendously minimize duplication, errors, and risks. Today, there are three popular application platforms - 1) J2EE, 2) .NET and 3) LAMP (Linux, Apache, MySQL and PhP). I think we will see more standards based platforms from the open source community in coming years that enable business solutions with more interoperable, coexistence and supportable services.

Lastly, on the development horizon, there are two popular Integrated Development Environment (IDE) platforms - VS.NET and Eclipse to develop applications on the application platforms. There IDE platforms not only drive the managed code to accelerate the software development life cycle, but also linked to project management and methodology life cycles.

Well, the platforms consolidation is another wave of IT shake-up that is taking center stage. It not only reduces the total cost of ownership, but also simplified the architecture for security and regulatory compliance.

Protocols
One of the building blocks of the infrastructure framework is the common communication protocol across the board. We came a long way to realize that HTTP is very viable protocol in the global market space. It is mostly understandable by firewalls and applications that can be controlled and monitored in a secured environment. For rich clients, there are a couple of other implementations such as RMI, JAX-RPC, .NET remoting etc depending on the security level, bandwidth, influence (firewalls will have a hard look at these protocols) etc. RPC over HTTP is also picking up in some areas for smart clients.

How do applications communicate on heterogeneous platforms? Simple Object Application Protocol (SOAP) is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the popular bindings are with HTTP and HTTP Extension. Such application protocols are becoming more standard in Service Oriented Architecture (SOA).

Common Services
One of the challenges in the enterprise is to identify the common services. We see tremendous duplication of functionality in the enterprise solutions. For example, the identity management is duplicated in every solution offering and it is a big mess in most of the enterprises. Similarly, SMTP services and workflow engines are duplicated to drive alerts, escalation process etc. If the enterprises focus on such common tasks and force vendors to leverage existing investment, there will be tremendous benefit on costs. It also simplifies the model where there is a single place to force strong security measures such as virus and spam filtering, and compliance measures such as auditing etc.

We should make sure that the applications comply with standards (RFCs, W3C, OASIS etc) so that all the products share the harmony on the common infrastructure. Vendors should provide best practices guidelines and support procedures for the coexistence and interoperability. Customers should also have proper policies and service level agreements (SLA) in place to keep the infrastructure healthy.

Solutions Architecture Framework
Having defined the essentials of the infrastructure, I will quickly sketch the ESA framework as depicted in picture 1. There are three major zones of the architecture namely - untrusted, DMZ and trusted. The common services normally hosted in the trusted zone, however, they can be also be hosted in perimeter zone depending on the sensitivity and security levels. Fundamentally, the entire infrastructure components are XML-aware. The legacy components may or may not aware of XML technology. The Enterprise Service Bus (ESB) could do tight integration between the legacy components and business services to participate in this endeavor.

Untrusted Zone: The end-user devices/applications (clients) and the public network (wireless and internet) clouds are normally falling in to the "untrusted zone". However, the clients are trusted only after proper claim/credential verification, with a duly assigned "Identity". Besides, a secured pipe established and proper authorization to the business services would finally make the end-user completely trusted. The business data being viewed within the XML framework, the communication transport being on HTTP for end-to-end solution (end-user to business logic), and the end-user presentation layer starts with the devices that are capable of supporting HTML /DHTML/XML to present the information in and out of a business service of the "data center" where, for simplicity, it is assumed that the services are hosted. The end-user devices are capable to access resources via wireless or internet clouds. In a 'service oriented architecture (SOA)', the clients could be either devices or applications. I may say that the client identity comprises of three major coordinates Person/Application, Device and Location (PADL).

DMZ Zone: This is the perimeter defense zone where the requests from the untrusted zone are centrifuged for its trust worthy. Here, there could be several layers of scrutiny to filter for a genuine request. The request is first examined for the identity and claim verification by IDM service in common services pool. It is the authentication process where the client gets a credible token for further computing. The subsequent trusted requests from client are routed to the business services for authorization with specific rights to different functionality. In most of the cases, the HTTP service in DMZ will take the responsibility for authentication. It then hands over other requests to the services in trusted zone over another firewall. It is a best practice to have a protocol transition from DMZ to trusted zone that could close security holes. In this perimeter zone, there could be some common services such as spam-filtering, virus-scanning, DoS attacks, Intrusion detection, etc.

Trusted Zone: As mentioned earlier, most of the business services are hosted in this zone with the front-end "web services (application architecture)" that first check for proper authorization to grant access the resources. The internal communication among the policy, authorization and resource services should be secured either using HTTPS or IPSEC or RPC. This zone has a couple of tiers such as business-logic, database, storage and legacy applications. Today, most of the databases are security aware and hence the data-provider tier access is authorized and the communication should be encrypted to protect sensitive data. This zone can also host the "common services" identified in an enterprise. The Identity Management (IDM), inbound and outbound SMTP services, etc are clear examples of common services. To improve the security in trusted zone, it is advised to implement secured communications among servers, for example, one can consider IPSEC connections for windows platforms.

Back-end (Soft Zone): The enterprises are loaded with many legacy systems are not fully aware of open standards. They are, being proprietary, are much secured but are expensive to manage. The "Enterprise Service Bus" along with adapters and connectors play a vital role in bridging the back-end legacy applications to the web-enabled business services. The best practice to preserve information integrity is to interface at applications level rather than direct interfacing at database service level.

Solutions Architecture Horizontals
The architecture is not complete without examining the entire solution for security, high-availability, scalability, manageability, business continuity, supportability and regulatory compliance across the board. The virtualization will hide the underlying technologies to make the infrastructure more open.

Security: As we have been touching this item right from the beginning, it is the most important factor to be considered in open computing. I would like one quick example. A friend of mine is a physician with his private practice. He has a small local area network with several workstations and physician application software. He did not upgrade nor apply security patches for the past five years. He never gets problem. I was so amazed and found the secret that his network is not exposed to internet! Well, that won't work for enterprise business community. Internet is a very cost-effective pipe and enterprises would like to take advantage of this wonderful technology. However, there are internal and external threats to the resources. Security should be considered in every component of the solution. There are several perimeter defense products covering "Unified Tread Management (UTM) to defend viruses, spyware, malware and phishing attacks. Packeteer and ProofPoint extend the perimeter to the application layer.

High-Availability: As business becomes more open to global marketing, the supporting infrastructure should be dial-tone ready. To provide 24x7 services, the components of the architecture should be highly-available end-to-end. Architect should examine vendor products for high-availability, sometimes on common technologies such load-balancing, failover etc. For some configurations, geo-clusters and geographic load-balancing are strategic to the solution. Consider hardware vendors like BigIP, EMC, Kashya, NSI etc.

Scalability: As enterprise solutions open to more and more users, the scalability is very critical to architecture. There are two models of scalability - a) Horizontal (scale-out) and b) Veridical (scale-up). Horizontal scalability, most of the times, address high-availability and platform costs, but will contribute to the management costs. On the other hand, J2EE or .NET based applications are not scaling beyond 2-4 processors. Architects should consider consolidating several solutions to utilize the platform resources. High-end server platforms (8-32x) address scalability and consolidation lowering the cost of operations. Data tier is the right place to consider for scale-up while app tier is appropriate for scale-out.

Virtualization: Traditionally, virtualization accommodates several platforms under the same hood to minimize the hardware. With SOA, the virtualization is extended to services. For example, the business services should not depend on the vendor supplied database provider. A virtual database service could manage several vendors' databases. Similarly, the database provider need not depend on the vendors' storage subsystem. A virtual storage service could manage vendors' storage subsystems. XML based messaging protocol does the magic!

Systems Management: One of the key success factors for enterprise computing is selection of a systems management framework. There are several frameworks such as HP Openview, IBM Tivoli, CA Unicenter, Microsoft MOM, etc that could accommodate the management of platforms, network devices, databases, storage appliances, end-user devices and applications. During the architecture design, when selecting the vendor products, architects should examine the management interfaces to do health-monitoring, backup/restore methods, problem escalation process, patch/software management, change management, storage management, database management, network management etc. Web interface is preferred so as to comply with firewall regulations. I recommend designing a dedicated management network, separating from the production network, with a management server open to administrators. SNMP is the preferred protocol to manage the resources.

Disaster Recovery and Business continuity: With the global marketing and 24/7 demand, businesses can not survive without a proper disaster recovery (DR) strategy. There are two types of DR - a) Component Disaster Recovery (CDR) at a location and b) Location Disaster Recover (LDR). High-availability technologies together with right systems management measures such as backup/restore will mostly address CDR needs. There are two models for LDR - i) Business Survival Strategy (BSS) and ii) Business As Usual (BAU). For BSS models, the components to support mission critical services (to support normal business operations) can be architected on a survival location in a standby mode with minimal resources. It is not easy to categorize 'mission critical services' without understanding the business and planning with business process management teams. On the other hand, the BAS model demands more components duplicated to one or two survival locations. In such cases, it is cost affective to implement Location Load Balancing (LLB) for the entire solution. There are some network products BigIP from F5 that could help such large LLBs. Architects should consider a) Business impact and risks; b) Recovery-Time-Objective (RTO) and Recovery-Point-Objective (RPO); c) Disaster Recovery plan; d) Disaster Recovery Training; e) Service Level Agreements; f) DR rehearsal schedules.

Support: Maintenance and support are the breathing factors for the long life of the architecture. Architects should make sure to have the right Service and Maintenance Level Agreements with vendors and user communities. Besides, the support personnel should be equipped with tools to debug and trouble-shoot the incidents having proper logs, traces and monitoring facilities, especially in firewall bounded services. Use always the management backbone network for support and maintenance rather than the production backbone network. There should be a knowledge base to search for repeated cases to minimize the service cycles on incidents. Known issues, tricks and workarounds should be documents and populate knowledge base. The buck starts from proof-of-concept validation in the lab. There should be an escalation process in place having at least three support tiers that include vendors support. Proper support procedures will enhance high-availability up to 5 nines. Proper training and awareness programs help the support staff to keep the architecture alive and productive.

Regulatory Compliance (RC): We now see that regulatory compliance is taking center stage in information technology shops as businesses are open to internet and intra-business operations such as supply-chain management. Outsourcing is adding another dimension to the complex model of e-business. Architecture design is not complete without complying with regulations. There is whole lot of confusion on what regulatory compliances would apply for a particular solution. In my mind, the infrastructure architecture design can address some of the common denominator across the RCs (HIPAA, ISO17799, SOX, GLBA, SEC, PATRIOT ACT, PCIDSS, etc., and other state regulations).

In the infrastructure model, there are three major security elements of concern - a) Identity; b) data & information and c) communications.

Identity: Not long ago before e-commerce and e-business became serious, the internet computing was very loose and it was like a kids play ground. Dotcomm sites used to attract audience by offering free e-mail and file services. People used to create their own usernames and passwords by sacrificing their own personal information such as street address, Zip, phone number etc. Some sites were gathering even the sensitive data such date of birth, ssn, mother's maiden name, etc. What is identity and what did we do to secure? Well, according Oxford dictionary, identity is defined as 1) "the fact of being who or what a person or thing is" 2) "the characteristics determining this". I would go with second to support first. I call "identity" is an object with a set of characteristics. It could be whatever combination of parameters such as latest picture, first name, last name, home address, home town, phone number, mother's maiden name, driver's license, bank account, thumb impression, digital certificate, smart card, eye retina whatever that create trust between two parties.

In today's computing world, identify is duplicated in the enterprise due to monotony of several silo applications that can not trust each other. In addition, the information flows over the wire un-encrypted. There are tremendous operational costs to manage these identity islands.

Some identity management products are helping to synchronize these islands. However, the risks of duplication and costs are not eliminated to ones satisfaction. Some interfaces are done at database level as the applications that manage these identities do not provide proper APIs. This is much more dangerous as the integrity maintained by applications could be disturbed. It is good idea to consider one of LDAP Services such as Active Directory, OID, NIS, eDirectory, Tivoli Directory Server, etc, that provide better security on identity management that can be deployed in common services pool and integrate with the applications. Some vendors such as Centrify are helping to provide to connect such directory services to applications from Apache, WebSphere, Jboss, Tomcat etc. Architects must conduct lab integration tests while evaluating these products.

Single Sign On (SSO): It is an ongoing sage to this story. Recent advances on "Federated Identity Management" are simplifying the authentication and authorization across federated web services to eliminate duplication of identity attributes. One such standard in pipeline is the SAML (Security Assertion Markup Language) that could provide SSO across business communities to ease the password mess. Vendors like PingIdentity are providing agents that could integrate with any directory services. Windows 2003 release 2 provides "Active Directory Federated System" that would bring AD based customer to do SSO. In SaaS model, the provider can mandate the SSO implementation and tie to the web services security (ws-security).

Data & Information: In legacy days, data is transformed to useful information by applications. The integrity is maintained mostly by applications. Data is protected at media level that can be handled by database services and physical libraries. However, in XML-aware infrastructure where the data is stored as information with tags, business-logic and database services work together to secure data for proper authorization, and apply policies and encryption. Besides, there should be physical measures to protect data. One of the major concerns on data protection today is the duplication of information in several islands. Applications claim several reasons such as high-availability, integrity, trust etc. Portal solutions are now able to provide a very large and highly available and trust-worthy information repository. It is now a good practice to categorize the information as a) sensitive; b) confidential and c) public. Architects must take measures to encrypt information at the repository level and access level. There are some Rights Management products that could apply policies on the documents and messages. Some vendors such as ProofPoint provide scanning tools to monitor and control the flow of the content on sensitivity and confidentiality. In SaaS model, the multi-tenant repository database services are challenged for trust on sensitive and confidential information. SOA will enable infrastructure for control and virtualization, ignoring the underlying specific products. For example, if business service needs to access data, it need not make requests directly to a vendor database implementation. Similarly, the database service need not put a request to vendor specific storage subsystem; rather it puts a request to virtual storage service that manages the underlying physical storage layer.

Communications: Secured communication is one of the most important components to comply with regulations. As a rule of thumb, communicate only on secured protocols such as HTTPS, LDAPS, and encrypted TCP traffic over the wire to prevent sniffing of sensitive information. Also, block dangerous ports at firewalls and servers. Some times, separation of external and internal traffic will not only enhance security but also balance the load distribution. Some management networks will help to apply policies quickly. Architects should make sure that the vendor products have audit capability that can be achieved and retrieved on demand.

Well, these measures will take more resources, but pay off down the road to do healthy business practices in the open global computing.

Simple Methodology to architect infrastructure model
There are several industry standard methodologies that help the architecture modeling. Many methodologies are focused on the application development life cycle and a few are focused on infrastructure development life cycle. In fact, new methodologies are emerging to simulate the physical architecture environments that include platforms, network, perimeter defense, firewall rules, protocol inspection, etc so that developer can check the code validation. Anyway, for this discussion, I consider a simple traditional modeling approach as depicted by steps in picture 2. The most important step is the proof-of-concept (POC) where one verifies the knowns and explores the unknowns.

The very first step is to start from the use-cases (requirements) by the business process management or program management team. Select a vendor product as baseline that could satisfy most of the requirements. The requirement matrix is then examined for the gaps. Research or get recommendations from the prime vendor for add-ons to fill the gaps. Otherwise, make a list of development items. Get best practices and recommendations from the vendors.

The next major step would to apply the vendor best practices and recommendations against the existing infrastructure, budgets, policies, governance, and processes. Do a due diligence on the price/performance and get the confidence level by looking at some customer references and benchmarks. Involve team members to evaluate feasibility, costs, risks, and time-to-market. There can be a go or no-go decision at this time.

Agree with vendors on the resultant architecture model with best practices that fits on the existing infrastructure. Sit down with vendors and simulate the model on the white board with best practices, standards, security, and compliance keeping the enterprise objectives such as high-availability, scalability, manageability, supportability and virtualization.

Make a list of items to be tested (with more emphasis on unknowns). For example, authentication, encryption over the wire, clustering, backup/restore, monitoring tools, logs and traces for support etc,. are to be considered in the proof-of-concept exercise. The intent of this lab exercise is not to do a full blown performable production system. But, it is to validate most of our assumptions (unknowns) towards an enterprise solutions infrastructure to host this solution today and several solutions tomorrow.

Construct the lab and make a minimal set of functional test cases with vendors and application teams that could touch every component of the architecture. Make sure that you document these procedures and the expected results. Also, come up with acceptance criteria that could give comfort level for the production.

It is also a good practice to do a couple quick load-tests, not full brown performance tests, for the architecture's survival (of the load-balancing technologies, web services, etc). For example, using Mercury Load-Runner or Application Center Test, a couple of loads can be simulated to put stress on the architecture. The expectation, at this level, would be that the architecture should not break down completely, though the performance is degraded. It is also a good idea to collect the capacity planning and benchmark documents from vendors to have an idea where the lab architecture stands.

Once the POC has been completed with an acceptable criteria, using capacity planning documents provided by vendors, come up with the architecture pictures for production, QA and test and development with proper sizing values. Make a deployment plan.

Architecting Virtual Collaboration Infrastructure
Let us examine a simple implementation. One company wants cost-effective and secured virtual collaboration infrastructure for the partners and customers to collaborate (on discussion threads, document sharing, and message boards etc) with the sales force using internet as vehicle. The company has budget constraints and would like have a fast cycle implementation with minimum resources. The company has a VPN/SSLVPN infrastructure in place, but is available only for to its employees. There are a couple of security policies in place such as a) internal employees should use VPN or SSLVPN from outside of the corporate network and b) internal employees are not allowed to change password via portal applications. Functionally, the infrastructure should host a portal application that accommodates several team sites where both company's sales teams and partners could share the information to quickly address the customer needs.

While the functional requirements seem to be simple, the infrastructure and security requirements are tricky. The company believes in scale-up and consolidation as it has been successful in demonstrating for several solutions. With the current support skill set and consolidation theme, the company locked down the server platform based on Wintel technologies. Besides, the company has a 3-tier firewall (2 for DMZ and one for intranet resources) infrastructure. Recently, company took extra measures to protect the privacy of external users to protect Identity Management services by additional firewalls and policies.

I have been attending Microsoft TechEd conferences since 1994 and often I am inspired by the presentations and exhibits on the emerging technologies. In 2004, I was attracted to Windows Shared Services (WSS) that is offered as an add-on to Windows 2003 server platform. As per functional requirements and the server platform constraints, I sketched the architecture diagram and discussed with the local Microsoft Consulting Services to make sure that the vendor supports the proposed configuration. With the help of the best practice documentation available in Windows Server Systems Recommended Architecture (WSSRA) and discussions with company's user community, I came up with the final architecture diagram that was agreeable to vendor and the IT folks.

With POC test, the idea was taken to the lab for simulation. I also conducted a simple load-test, not for capacity planning, to make sure that the solution survives for a typical web hits. There were a couple of challenges and surprises, but at the end it was an acceptable solution to go for production. Surprisingly, there was only one development task for an ISAPI filter to block employee login over internet.

The front-end web/app-tier has two Windows 2003 Standard Servers with Network Load Balance (NLB), a scale-out cluster topology for IIS/WSS services and is open to the internet over the perimeter firewall. The backend web/app tier is connected via firewall to the data tier comprised of two Windows 2003 Enterprise Servers with Microsoft Cluster Service (MSCS), a scale-up cluster topology for SQL server 2000.

The storage subsystem (EMC Clariion) over SAN fabric with redundant Brocade switches is connected to the data tier. The backend network is also connected to the Common Services tier over firewall. The Common Services tier comprises of an external forest with two Domain Controllers on replication cluster topology, and the SMTP servers on scale-out cluster topology.

The architecture supports SQL server 2005 cluster with mount points that can host several SQL instances for consolidation. Corporate (intranet) and support (management) network is connected to the solution via backend firewall. Both external and internal services are consolidated to two physical servers and load-balanced with two different network interface cards to separate the traffic. Also, Microsoft client network and print services are removed on the front-end interfaces to harden the security. The perimeter firewall allows only HTTPS (443) requests from the global internet.

To comply with company's security policies, the traffic over the wire is encrypted for all the interfaces. Certificates are installed on SQL server cluster nodes to encrypt the TCP traffic between web-tier and data-tier. Also, SQL server file system is chosen as "Encrypted File System" to protect against any data-lifting. A one-way trust from external domain to the internal domains is established to protect internal resources. Windows 2003 authentication firewall feature is deployed to allow internal users to access WSS application in web-tier.

Each IIS/WSS server platform hosts two virtual servers - 1) wss-extranet-site for external users and 2) wss-intranet-site. For high-availability, the four virtual servers are load-balanced with two NLBs (one for internal and the other for external).There are two virtual IP (VIP) - one dedicated to internal and the other to external. The external VIP in global internet DNS server and the internal VIP in intranet DNS server are pointing to the same URL. All the four virtual servers will access the same content repository in the SQL server 2000 cluster. The SQL server is a Kerberos trusted service in the External Active Directory. The access to SQL server from WSS is configured for a Kerberos trusted account for delegation. The Windows 2003 servers in web-tier are configured for protocol transition to Kerberos for authentication.

On the wss-extranet-site, there are two additional services on a) password management that is provided by IISADMPWD module (Microsoft supplied add-on) and b) block requests from internal users trying to access from internet (custom coded ISAPI filter). The wss-extranet-site is configured for basic authentication over HTTPS to support any browser from the external users. The servers are configured for a protocol transition while talking to Domain Controllers.

On the wss-intranet-site, "windows authentication" method is selected to support company's windows desktop network. To meet the company's requirement to disallow internal users for password changes from this solution, wss-intranet-site is configured to disable the password changes while wss-extranet-site is enabled for password changes. The company users use the same desktop credentials to access the portal site as a single sign on feature.

The advantage of windows 2003 platform is to implement native Kerberos and IPSEC to secure communications among servers.

Source: Line 56