Multiple Types of Entry, One Application
Within a collaboration environment, it is common to have multiple typesof entry for a singular web application that will resolve to the samecontent for varying types of users (not even in the context of a webapplication in MOSS, a .NET web application even in general). Forexample, customers may enter through one URL to access an extranet thatyou output sales metrics through whereas end users enter through anintranet URL using local domain accounts to view those very samereports all through your various MOSS site collections.

In order to procure an environment where it becomes much easier tobuild grouping and sorting of these diverse entry points that althoughwill bind to the same content, yet provide granular control that canhook to such things as security policies or authentication providers,Microsoft Office Server System builds off a concept known as zones.

Because of this paradigm of people entering a Microsoft OfficeServer System environment from a variety of access points, zones are anecessary portion in order to properly architect a SharePointenvironment. Since in most perimeter deployments it is exceptionallycommon to have these types of multiple entry mechanisms, specificallywith multiple types of authentication providers, it is necessary toexplore the concept of zones.

Before the concept of zones becomes apparent, it is best to stepback and look at the basis technology that provides the granularframework that zones implement, Alternative Access Mapping (AAM),authentication providers, and web application policies.

Alternative Access Mapping (AAM)
Alternative Access Mapping, although crucially more important in thisrevision of SharePoint, is a borrowed concept from the 2003 version.AAM builds up the central factory of how users are redirected uponentry, and through there entire stay on your MOSS instance. It soundsvery fancy, however AAM provides the backbone of how the URL formattingwill happen throughout the entire user experience. What it provides ismultiple entry points to a singular web application, as opposed tohaving all users conform to a singular point of entry, that others maynot have access to. This becomes increasingly important when you arecreating multiple facing deployments, such as those that will face bothan internal set of users, as well as an extranet scenario wherebypartners and other trusted individuals may attempt to get access toyour MOSS instance. What AAM provides is the method to conform to alogical URL, a URL that is familiar to users and conveys the meaning ofa site, as well as maintaining URL formatting conventions since howusers will enter a site internally (usually just through ahttp://sharepointsecurity) is different than how external users willaccess it (typically something like(http://extranet.sharepointsecurity.com). Whatever the URL standard iswithin your organization, multiple points of entry are achieved throughAlternate Access Mapping.

Besides some of the neater features that AAM provides, there arealso several rudimentary problems that is solves as well, such askeeping search results uniform. If AAM didn’t exist, it would bepossible that a user may return results via an improperly formatted URLwhich may, in turn, lead to an ugly access denied screen.

The default URL, which is bound to the default zone, in thebeginning is setup for you by default. If you are only going to haveone points of entry for your application, then you have no need toimplement any further modifications to the AAM settings. Clearly,having the same URL entries within AAM is not possible, since it ismeant to promote the segregation of the URLs that an arbitrary user mayuse when attempting to gain access to the site. If, for any reasons atall, one of the production URL’s that AAM is using is deleted, it isimportant to realize that the relevant content DB’s must be updated toreflect this change, otherwise there will be ghost site resultsreturned on various pages.

Policies and Authentication Providers
While the concept of AAM is a neat idea, however it doesn’t really showthe power that can exist when you bind them with the concept of Zonesin MOSS. MOSS Zones are a method of logical grouping of your AAMsettings that both

  • Provide an Easy Way To Inventory Your Points of Entry and URL Standards
  • Allow the Binding of Authentication Providers and Web Application Policies to Various Entry Points

MOSS Zones don’t have to imply different policies or authenticationproviders, however they can or don’t have to be closely hookedtogether. This at first may seem confusing, however the concept initself is rather simplistic in design an purpose. Consider thefollowing three scenarios:

  1. You have an end point for extranet clients and one for intranetusers. The entry URLs for a singular site may vary heavily, an extranetpartner will enter through extranet.x.x whereas the internal customerswill use an entry point such as intranet.x.x. These are to becategorized into easily distinguishable zones such as intranet for thelatter, and extranet for the former, respectfully. For the case of thepartners, you want them to all use forms-based authentication with aSQL membership provider, and for the internal users you wish tomaintain Windows Authentication so that they can just pass theirrelated Domain Login tokens directly to the portal. Using Zones, youcan bind the SQL membership provider to the extranet zone after settingup the URL entry through the MOSS AAM settings, and use the “intranet”zone in order to bind the standard windows authentication scheme forall internally entering users.
  2. You have an endpoint for internal users that have domain accounts,and internal users who are considered temporary. The entry URLs for asingular site may vary heavily, the temporary personnel will enterthrough temp.x.x whereas the internal, permanent employees will use anentry point such as intranet.x.x. Because the temporary employees areonly required a short duration on their specific intranet, and neverhave write or full control rights on any of the content, one can simplybuild the appropriate URL entries into the AAM settings of MOSS, andthen configure the membership provider for SQL which will cut down onthe operational work of the network administrator since he does nothave to go through AD in order to make them accounts (unless, ofcourse, they require them to login. This is a proof of conceptexample). The internal users could still login via apermanent-formatted URL which would let them use their domain accounts,and whereas the temporary employees have a web application policy thatrestricts them to read only, the granular security of MOSS for SecuredObjects are still available to internal employees for proper Item-LevelSecurity settings.
  3. It is a requirement that external clients need not learn anotherpassword in order to login to view the sales metrics that you havesetup through your MOSS environment. They have to be able to enter,through a specific URL that you have setup through AAM, and use theirown corporate domain credentials in order to view the reports. Internalemployees, however still need to be able to use their internal accountcredentials in order to login once they have properly invoked theWindows domain token for identity verification. Using Zones, you couldsetup an “extranet” zone that would use the HTTP module provided by theMOSS Web Single Sign On functionality, and following be able toassimilate the identities of the extranet users in order to allow themthe use of their own corporate credentials as they login to the site.Internal users will still be allowed the functionality of using theirdomain credentials because they are setup in the intranet zone bound tothe Windows Identity in the authentication provider in WCAM.

Although zones are a relatively simple concept in theory, they allowthe exploitation of some true power behind what SharePoint allow inregards to authentication and web application policy binding. It iswise to plan zones correctly, they are how the user is going to betraversed throughout your web application as well as how they areauthenticated, along with right overriddance provided by webapplication policies.