extended web apps, a primer on AAM, and why I don' think they secure the way you think they do...

So I am working on the edits for the web application chapter and I am at the end, where Alternate Access Mapping was introduced by, ironically, first extending a web app (not exactly what I would have done, but that's what happens when you give the chapter to another author). It's after that extension though, that everything comes together, the creation of the blogging web app earlier in the chapter, the anonymous access, the self-service site creation, the host header intro. And it is then that I really realized something that had been bothering me.

Alternate Access Mapping is purely a way to teach sharepoint what URLs to respond to, and what content to point them at when they come calling-- with a dash of misdirection if the URL it sends back isn't the one sent by the user initially. But it is also tied up with extending web applications in a way that almost makes me feel insulted.

Before we get to that, here's a pretty beefy primer on the Alternate Access Mapping concept so you understand where I am coming from here (and where I might be going wrong if you want to skool me):

You can have web applications that hold site collections that contain a structure of sites and subsites consisting of pages containing lists, libraries, and web parts (most of which point back at the lists and libraries). All of the site collections get their data for those pages from the content database(s) used by the web application. The site collections get their web addresses from appending their path to the web application's address, like http://sharesrv/sitecol1/.

And if that web application's contents are successful, a lot of your users will want to use it, and may want to use it from several different places-- like the office, home, and at branch offices. So to give those users access to those site collections, you have to somehow get Sharepoint to accept more than one URL for the same web application.

Therefore you can use Alternate Access Mapping and just associate some URLs to the same web application, meaning you can have http://sharesrv for the internal office users, and http://sharesrv.mycompany.com for the external users. As long as DNS is set up correctly, then both URLs will go to the same web application.

So why would you ever want to extend a web application? I really had to wrestle with this concept (no, not to understand the concept, but to understand why). An extended web application is where you create a second IIS Web Site that uses the same application pool as an existing web application. This means the extended web application uses exactly the same content as the first web application.

According to Microsoft and people who repeat what they say, you want to extend a web app' because that second web app' can use different security and a different URL. And if you give that extended web app's URL to users that need to be constrained by that extended web app's security, they will use that URL and be constrained. And what is really pushed is the fact that Alternate Access Mapping is a thinly veiled way of managing the URLs of your various extended web applications.

Sharepoint handles URLs as internal and public (external). Internal URLs are what sharepoint gets from the user, accepts them, and sends back the appropriate data. Public URLs are what sharepoint uses to show the user it's links and usually the internal and public URLs are the same.

That makes sense to me, if you want a different URL for a web app to be accepted by sharepoint, you use a public URL (which made its own internal matching URL for resolution purposes only) and point it at the correct web app. Then the user (if DNS is set up correctly) uses either URL and still gets to the web app. Case closed.

All web applications have one real internal URL and five public URLs they can use. Yes, five. Why five you ask? I ask that too. This where MS muddies the waters. Instead of having a nice clear concept of using alternate URLs for web apps, they decided that, in addition to doing alternate URLs, sharepoint will also use the public URLs as the only way to create and manage URLs for those extended web applications.

Remember those? Extended web applications are IIS Web Sites that point to the same content for, apparently the sake of having a different URL than the original web application and for the sake of being able to explicitly set things like authentication and SSL on the extended web app that is different than the original web app.

You can only have four extended web applications per existing web application by the simple expedient of having only four fields available (default is taken by the internal address of original web app itself). These public URL fields are called zones, and you select from the available ones for a web app being extended when you are filling in the settings for the new extension (so to speak). When you fill in a zone address, which is a public URL, it also creates a matching internal URL so that sharepoint uses that address coming and going, you could say.

Say you wanted to have more than one URL go to the same web application, and you decide not to just type one in one of the public URL fields, but instead you decide to create an extended web application for it instead.

So, you use the URL you want for the extended web app, and assign it a public URL zone. Back in Alternate Access Mapping that public URL will be taken. Everywhere else in the administrative interface for sharepoint, that extended web app will be referred to by its zone name. So if you want to change its security settings or whatever, remember that you need to remember its zone. You won't be seeing it by it's URL anywhere. Furthermore, it's not considered "real", so if you want to make any general web app changes (like enable the metaweblog api), you can only do that for the "real" existing web app it was extended from.

Anyway, you have an alternate URL to access the original web application's contents. You can apply security to that extended web app so the users who use its URL to get to the content will have to comply with its security requirements, like SSL or Kerberos (eek).

So now you're with me: how using extended web apps ties up and limits Alternate Access Mappings to these arbitrary four public zones. Muddying the clear waters of alternate addressing with forcing the alternate access for an existing web application to a few public URLs with a strong insistence that those should be extended, extra IIS Web Sites pointed at the same data.

And also I have a concern about this whole alternate web apps with different URLs thing implying that it will somehow secure sharepoint sites by simplygiving the different groups of users the URL you want them to use.

And, of course, that'll work, right? They'll just be happy using that one URL. They won't confer with their buddies and find out that james uses a different URL than they do, one that lets him see things on sharepoint pages without logging in, right? And, even if they did, they'd never be tempted, nay driven, to use that URL instead, would they?

I find the idea of security through expecting users to freely comply to be bad practice. Unless you have only one internal URL for the office, and one URL for outside of the firewall, I don't see how the users are not going to figure out how to cheat. Hell, internal users can use the external address if they want to, so even with two URLs, half of the users can be exposed to data they possibly shouldn't, or security settings you weren't expecting.

And that's why I am bothered by zones, extended web applications, and alternate access mapping. Because they strongly imply that admins must create more IIS web sites to use for public URLs, which they seem to think will corral those users and get them to access the site collections using only the URL they suggest. And then, to allow only four public URLs per web app, adds insult to injury...

...Frankly, what I have come up with, and this seems to be true of most things sharepoint is that there is no why to a feature that is there, or how it works, or how its set. The point to sharepoint is not that it was meant to do something in particular. Often we find a use for it that has nothing to do with what we were told it was meant to do, we use it because of what it does. The point to sharepoint is not that the option, feature, or setting is there, specifically, for a single use or reason. The point to sharepoint is that the option is there if you have a reason for it. If you want it, extended web apps are there for you. If you want, you can use the public zones for URLs you type in that are not part of the extended web apps. You can use SSL, Kerberos, or Anonymous Access on either or both the original web app or the extended one. And, finally, you can try to tell only those users who need to have a certain kind of access to use a certain URL. It's up to you.

This is how I am feeling during the last few hours of editing chapter 8, if you're wondering.