Introducing Cloud Integration Services - Microsoft Dynamics CRM Team Blog - Site Home

Its official – at Convergence last week, we launched the third wave of CRM Online: the March 2009 Service Update, known under development as “R3”. Besides the 99.9% SLA and Internet Lead Capture work, we invested heavily in Cloud Integration Services. It’s now easier than ever for an ISV to develop services and solutions which interface smoothly and securely with CRM Online tenants.

As the program manager for the feature, I want to give an extremely high-level overview of the scenarios we’ve delivered. Look for further information in the current SDK release, the next SDK release, future MSDN articles, and right here on this blog (as well as our sister blog, run by the Technology Specialists for CRM Online) for in-depth coverage, how-to, etc.

At a high level, we’ve eased the development of two patterns:

Service to service integration. Say you’re an ISV with a web-based service that needs to put data into CRM without regard to the ownership of that data. (Maybe you want to use some workflow logic to assign the records once they’re inside the system, so it’s fine for the data to be owned by no one. Or maybe the service only reads data, and users initiate sharing with the service as needed.) This level of integration is accomplished by associating a certificate to a Windows Live ID, then using that Windows Live ID as a service account in the customer’s org. Each customer organization gets 5 free service integration licenses, tracked by setting the Access Mode to “non-interactive” on those users. Mostly, service-to-service underpins the ability to do the next level of integration, described below.

Impersonation or on-behalf scenarios. In this case there are two identities involved – the ISV service account as above, along with a real user of CRM. In a nutshell, the ISV will get the user’s identity relative to Windows Live ID (called the PUID), then it can use its service account to call a new method in the discovery service to trade the PUID for a CrmUserId. This method is called GetCrmUserIdByExternalId. Finally, still using the service account, the ISV can make calls to the org-level webservices and stuff the CrmUserId into the CallerID field just like on-prem impersonation. The records will show up as being CreatedBy/ModifiedBy the impersonated user, but CRM will record the identity of the service account in two new fields: CreatedOnBehalfBy/ModifiedOnBehalfBy.

There are a couple of caveats that I should call out:

I haven’t described any recommended architecture here. Clever ISVs will note that they only need one certificate with one service account to serve multiple CRM tenant organizations if they run a cloud-based service. Future articles should make this a bit more clear.
I also haven’t fully described the security architecture here. One of our mitigations against malicious code was to implement a privilege intersection requirement. What does that mean? Both the service account and the impersonated user must have a particular privilege in order for the system to allow an action. In this way, the impersonating ISV can’t take over the full privilege set of a user (unless the administrator of the organization has allowed it), nor can a regular user elevate his privileges via an ISV application. The image below illustrates this graphically. The real user has 3 privileges, and the ISV service account has 2. However, when the ISV impersonates the user, the system will act as if the ISV has only privCreateLead, since that’s the only privilege both identities share.
Finally, the association tool needed to connect a certificate to a Windows Live ID (to create the service account) has not yet been released by the Identity Services team. Look for that to ship sometime between now and 3/31.