Deploying SharePoint 2010 Extranet
These are some notes from a session today at the SharePoint Conference 2009 in Las Vegas delivered by Ryan McMinn, an Access Services guy at Microsoft. It was nice to get more specific information about getting FBA to work, but it was also a little frustrating to not get much information about setting up SharePoint to trust external claims providers. It’s touted as the best answer for partner collaboration, and I anticipate it to be a big winner for sites the interact with large numbers of individual contributors (think LiveID users), and earlier sessions pointed to this one as having all of the implementation details – but it seems like most of we get are concepts and generalities so far. The notes are as organized as I can make them while I’m sitting here in the room, but they will of course not be as polished as I’d like them to be. I’ve decided to err on the side of more information – less polish.
Design Considerations and Business Requirements
- Account Management
- Network Access and entry points
- Single Sign On
- Information Disclosure
- Antivirus
- Rich Client Experience
Target Audiences
Remote Employees – Need to use their internal identity. Need access to Line of Business apps, collaboration, and publishing content.
Partners – Need to use both internal and / or external identities. Need access to limited sites and data (no other partner data).
Vendors and Customers – Need to use external identity. Need access to targeted and segmented content for collaboration and / or publishing content.
We must also think about zones and Alternate Access Mappings (or host named site collections). The Default zone should be the most secure (SSL), because it is the fallback zone in case of problems
Authentication Issues
Claims Based Authentication can use Windows Integrated, Forms Based (ASP.Net or LDAP), or SAML. When you create a web application, you pick between Windows Classic or Claims Based. You can still use separate zones for different authentication methods. However, if you choose Claims, then multi authentication can be used in the same zone (as long as they use the same protocol – HTTP or HTTPS). This is much like what Outlook does with RPC over HTTP (using Windows Integrated when possible, and prompting when not). The authentication page first asks which method you want to use for login. This happens in the browser or in the rich Office clients.
There is not yet any documentation about how to configure the SharePoint STS to trust external claims providers such as LiveID or external federated domains. The short version is that they must be installed into the store, and then PowerShell commands are used to register them for use. Microsoft requests us not to go into production with Beta2 Claims Based functionality, but will provide instructions to test it there and wants us to do so.
There are some specific steps necessary to make FBA work in 2010.
- Setup the authentication provider
- Setup the web app to use the authentication provider
- Add authentication provider to the web.config files of:
- Central Admin
- Web Application
- STS
This can be done via PowerShell (if you are upgrading an existing web application you should do this BEFORE attaching the database for upgrade).
- new-spauthenticationprovider –aspnetmembershipprovider “membership” –aspnetroleprovidername “rolemanager”
- new-spwebapplication –name “my web app” –applicationpool “claims app pool” –applicationpoolaccount “domain\appool” –url http://servername –port 80 –authenticationprovider “membership”
ForeFront Unified Access Gateway 2010 (formerly IAG, Intelligent Application Gateway, which apparently is the yet again renamed replacement for ISA 2006) allows you to leverage existing servers without replication, a DMZ, or more servers. It uses wizards to publish sites, do link translation, supports AAM, and path blocking. It can also apply more specific rules (upload, download, edit…) based on identity, role, and endpoint device (corporate desktop vs. home PC). It can also handle authentication with multiple directories and 2-factor tools, and provides excellent single-sign-on.
Forefront Identity Manager 2010 synchronizes identities and passwords across systems, automates user provisioning and management, and can be used to delegate this ability to partners.
Forefront Protection for SharePoint 2010 scans for viruses and malware, filters inappropriate content, and notifies administrators for infractions.
Will SAML-Claims allow users to log into SharePoint even if they don’t have a Windows account in the domain the SharePoint server lives?
If so, are there any limitations to things such as assigning “Tasks” (apologies if this isn’t the best example as I don’t use SharePoint that much) to a particular user when no record is preestablished for that user?
That’s exactly the intent of Claims-Based-Authentication. It gives the SharePoint admin the ability to authorize external users – giving them access to SharePoint resources without having to create a domain account for them. It fills a need similar to what has previously been addressed by Forms Based Authentication. In fact it can include FBA, but now makes it possible to use other pre-existing third-party accounts as a means to grant access (or make assignments). Pretty cool, huh?
That is cool. I don’t quite understand the act of assigning something to another user, though, if they are a SAML-Claims user. For example, say an enterprise (Service Provider) is running SharePoint and they have a federation trust with a partner (Identity Provider). Now say Eric at Identity Provider should be assigned to something in SharePoint, but SharePoint has no preexisting record for Eric. Is that assignment possible, or would it be done some other way?
I haven’t played with Claims Based Authentication yet, because it’s functionality is incomplete in the current beta version. However, in this sense it seems that it will be a similar paradigm to Active Directory users. SharePoint only stores information about a user once they have been given permission and have logged on. However, you can find them through the People Picker in order to grant permissions. The People Picker currently looks up users in AD, LDAP, or ASP.Net. It will now be able to look up users in other external sources.
SAML is the markup language used to create the security token. It’s not how the user is stored, it’s how it is described in a standard way to SharePoint from another Identity Provider.