SharePoint Health Check-Up can improve stability and performance of your SharePoint
SharePoint Managed Services to improve system reliability.
SharePoint works very well as an intranet and it also can work well as an extranet or business-to-business portal. Getting the securely published is the topic of this post. Designing extranets typically requires thoughtful consideration of information architecture in regard to security. This post reviews several common scenarios.
SharePoint Server 2010 supports authentication methods that were included in previous versions and also introduces token-based authentication that is based on Security Assertion Markup Language (SAML) as an option. The following table lists the supported authentication methods.
Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication. In SharePoint Server 2010, forms-based authentication is available only when you use claims-based authentication.
SAML token-based authentication
Supported only with SAML 1.1 that uses the WS-Federation Passive profile. Client certificate authentication is possible through integration with AD FS 2.0. For additional information, see Configure Client Certificate Authentication (SharePoint Server 2010).
SharePoint Server 2010 introduces claims-based authentication, which is built on Windows Identity Foundation (WIF). You can use any of the supported authentication methods with claims-based authentication; or you can use classic-mode authentication, which supports Windows authentication.
Claims-based authentication is built on WIF, which is a set of .NET Framework classes that are used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.
In edge topology, a single network firewall stands between external users and internal SharePoint sites. It has the advantage of using a single Active Directory environment for internal and external users, which simplifies maintenance and administration. To secure traffic via TLS, you configure the firewall to also act as a reverse proxy. The concept of an integrated reverse proxy such as ISA or TMG Server is vital for securing Internet-facing sites, because the reverse proxy intercepts incoming requests, can authenticate external users, decrypts TLS traffic, inspects it according to firewall rules, and forwards requests to front-end servers. Public URLs may differ from internal URLs, so the reverse proxy must have a means to perform link translation to convert external URLs into internal URLs. UAG Server provides additional security capabilities, such as end-point, health-based authorization through an access policy based on user identity and client computer health, and the ability to translate links for internal SharePoint URLs when using Outlook Web Access By using a set of configurable rules, the proxy server verifies that the requested URLs are allowed based on the zone from which the request originated. The requested URLs are then translated into internal URLs.
This configuration results in a single firewall that separates the corporate internal network from the Internet.
You are not limited to just two firewalls in a back-to-back topology. You can implement additional layers separated by firewalls or routers to further separate the SharePoint roles. For example, you could use a three-layer approach, putting each layer in a DMZ, where front-end servers are first, followed by application, database and search/index server, and concluded by Active Directory/DNS servers. You can also customize a back-to-back topology to include an internal staging environment in a separate farm and publish it to the farm in the perimeter network.
Content is isolated to a single farm on the extranet, simplifying sharing and maintenance of content across the intranet and the extranet.
In keeping with the approach of using security layers in the topology, front-end servers reside in the perimeter network and the back-end servers running SQL Server reside in the internal network. The remaining roles, such as index, search, and central administration, can be in either network. This topology splits the farm between the perimeter and corporate networks. The computers running Microsoft SQL Server® database software are hosted inside the corporate network. Web servers are located in the perimeter network. The application server computers can be hosted in either the perimeter network or the corporate network.
If the server farm is split between the perimeter network and the corporate network, a domain trust relationship is required. There are two AD domains for the Intranet and extranet - say DOMAIN and DOMAINEXT. DOMAINEXT is in the perimeter network. Servers in the perimeter (DMZ) network are joined to this domain. In this scenario, the perimeter domain must trust the corporate domain. DOMAINEXT trusts DOMAIN with a 1-way trust.
You set up the farm as you typically would internally within DOMAIN. You then join a WFE in the perimeter network to the farm. Since this WFE is joined to a domain that trusts the internal domain, it can use the same service accounts, etc. However, if someone hacks the WFE and gains access to the extranet domain, they can't do anything to the internal domain as DOMAIN does not trust DOMAINEXT.
The only scenario in which a domain trust is not required is if the Web and application servers are in the perimeter network, the database servers are in the corporate network, and SQL authentication is used. However, if the Web and application servers are split between the networks and SQL authentication is used, a trust relationship is required.
About this diagram:
Mention this post and we'll send you a white paper about how to best utilize SharePoint!