Understanding Business-to-Consumer Scenarios
Updated: July 15, 2011
Applies To: Windows Server 2008, Windows Server 2008 R2
Business-to-business collaboration solutions enable sharing rights-protected content between organizations that implement the infrastructure components that make up the solution. Each organization must be able to deploy their own Active Directory Rights Management Services (AD RMS) infrastructure or federation solution to make the collaboration solution possible. However, frequently this can present an insurmountable barrier to these solutions. Many smaller organizations do not have the IT resources that they must have to deploy AD RMS or federation components to implement their part of a solution, or they may just lack a basic component, such as an Active Directory infrastructure.
When you cannot reasonably implement a collaboration solution between organizations, it is still possible to exchange rights-protected content between your organization and individuals inside another organization or even without an organization affiliation. Because these solutions focus on collaborating with individuals instead of organizations, they are referred to as business-to-consumer solutions.
Depending on your needs and resources, you can select a solution that gives you control over the identities of the users you will be sharing rights-protected information with, or you can decide a solution that relies on an external identity provider (Windows Live ID) to maintain the identities of and to authenticate external users.
The following sections explain each of these alternatives and the benefits and tradeoffs involved with each of them.
Trusting Windows Live ID to authenticate external users does not require your organization to be responsible for managing accounts for your external users. Instead, you rely on Windows Live ID to authenticate those users. When an AD RMS cluster trusts Windows Live ID, external users who authenticate by using Windows Live IDs can open and modify rights-protected content sent to them from inside the organization (that is, they can receive a use license for the content), but they cannot create their own documents or messages that are rights-protected by the organization’s AD RMS cluster (that is, they can’t receive a publishing license from the AD RMS cluster).
For more information, see Using Windows Live ID to send protected information to customers.
When considering whether trusting Windows Live ID to authenticate external users is the most effective way to provide rights-protected information to users outside your organization, you should consider the advantages and disadvantages of this approach.
Using Windows Live ID has the following advantages:
Minimum deployment effort Apart from making sure that your AD RMS cluster is available to users on the Internet, little administration is required apart from enabling the trust relationship and configuring trusted or untrusted email domains.
No identity management overhead Because identities of external users are managed by Windows Live ID, there is no need for internal IT staff to provision and maintain accounts for external users. Internal users have the flexibility of sharing rights-protected content with any external user without requiring that an account be created for the external user and a new set of credentials sent to the external user before the rights-protected content can be used.
Can work with any email address If external users have not already done so, they can associate almost any email address with a Windows Live ID account.
Securing the licensing pipeline When you use Windows Live ID to share rights-protected content with users outside your organization, you must make sure that your AD RMS root cluster is available to those users, usually by making it available on the Internet; see Appendix A: Making AD RMS Available on the Internet for more information. You must then configure the permissions that protect the cluster’s licensing pipeline (license.asmx on the host Web site) to enable access by external users. Typically, for cross-organization collaboration this means enabling anonymous authentication, which might be considered a security vulnerability in some organizations by making it more open to a denial-of-service attack. AD RMS always uses the rights account certificate (RAC) for authentication, however, so enabling anonymous authentication does not put information secured by AD RMS at risk.
Reliance on Windows Live ID authentication Some organizations might have network security standards that exclude relying on external authentication authorities when they share sensitive information.
Windows Live ID users cannot use the AD RMS cluster to protect content External users who authenticate by using Windows Live ID can open rights-protected content and, if given the necessary rights, save changes or reply to that content. When they use their Windows Live ID to create rights-protected content, however, anyone who receives the content must log in with a Windows Live ID to use the content.
Limited functionality Because the identities of external users are maintained outside your organization’s Active Directory infrastructure, any AD RMS feature that relies on Active Directory cannot be used when you share rights-protected content with external users who are authenticated by Windows Live ID. Examples of these features are group expansion and rights-policy templates that control how individuals or groups can use content protected by the template.
By far, one of the simplest (conceptually, at least) method of deploying AD RMS to enable collaboration with external users is just to deploy AD RMS so that it can be accessed from the Internet. Of course this means that, as with your internal users, you must provision and maintain the Active Directory accounts of all your external users as well. Furthermore, if you don’t want to expose your organization’s own domain controllers and AD RMS servers to the Internet, you will likely want to implement a separate forest for your external users and establish some kind of trust or federation relationship between your internal and external forests. To learn various ways you can do this, see Appendix A: Making AD RMS Available on the Internet.
For more information, see Deploying AD RMS with account provisioning for external users.
When considering whether deploying AD RMS with account provisioning for external users is the most effective way to exchange rights-protected information with users outside your organization, you should consider the advantages and disadvantages of this approach.
Deploying AD RMS with external account provisioning has the following advantages:
Simple to deploy Deploying this approach is almost the same as deploying AD RMS in your organization, especially if you do not want to deploy and provide interoperability with an internal AD RMS infrastructure.
External forest useful for other purposes If your organization has significant contact with outside customers or partners, there’s a good chance that you have already implemented an external forest that can be used for this purpose, or that you can use an external forest deployed for this solution to help meet other business requirements, such as using SharePoint Server to provide shared calendars and project lists.
Simplified trust model Even if it’s necessary to implement internal and external Active Directory forests and AD RMS domains, the trust model required to provide interoperability between them is greatly simplified when you compare it to the trusts that must be established with multiple external organizations.
Costly to maintain While this approach is relatively simple to deploy, it is also relatively expensive to maintain because it requires the individual provisioning and management of the individual accounts of external users. This might not be a significant consideration if the number of external users is few, but if your organization must support many external users, this can prove to be a significant expense unless you can automate these tasks.
Separate identity for external users This solution requires that users maintain yet another identity in addition to the other identities they own for other Internet applications. This can compromise the security of your external forest because users will be inclined to use the same credentials for multiple security contexts.