Power users and vendors are always excited about SDKs to their favorite applications. The ability to build solutions on top of powerful interfaces can go a long way towards extending the capabilities of a product. CRM’s SDK is proof of that; but when it is applied in a CRM Online situation, the challenges inherent to cloud computing mean the technical hurdles are higher.
Authentication is the primary culprit. To authenticate to the CRM Online system you need to obtain a Windows Live ID (WLID) ticket, and the only way to do that has been to dance to IdCrl’s tune (there are actually ways to bypass IdCrl, but they are unsupported.) IdCrl is only intended to be used when there’s ‘a warm body at the keyboard’ to enter credentials, so service accounts (who are often more useful when it comes to taking advantage of SDKs) weren’t invited to the party. On-premises and partner-hosted deployments have been able to simply let Active Directory handle all aspects of authentication, which has no such limitations.
Fortunately, recent functionality additions to Windows Live ID allow CRM Online to reach parity with its counterparts. SDK consumers will now be able to use certificates to obtain WLID tickets. This opens up a wide range of possibilities that can expand CRM’s functionality with web services and third-party solutions. The CRM Online team recognized that once service accounts were able to do business in CRM Online, impersonation would need to be supported. So that’s an area where complementary improvements were made.
The main obstacles remaining are the expense of obtaining a certificate, and, for impersonation scenarios – the fact that it’s fairly involved to manage Windows Live identities for the amateur developer. You’ll need to register your app with Windows Live and make use of their Relying Party Suite (RPS) libraries. This allows, for example, the ability to obtain the unique id (aka puid or Net Id) of a user browsing your site when they’ve signed in with their WLID account. You’ll need that unique id, among other authorization prerequisites, if you want to impersonate that user in CRM.
For example, a vendor could build a service to provide an easy way to send a small gift to a client after closing a sale (perhaps with real estate agencies in mind.) This service can be added to your CRM Online organization by configuring a page from the vendor’s web site to appear as a tab on your account form. The vendor’s page allows you to make a gift selection and send it with one click. To put the icing on the cake, the vendor could suggest customizations to your data model so that records of gifts associated with accounts would be kept and gift expense items are saved to another table.
In addition to the aforementioned configuration tasks, there other prerequisites needed to enable this scenario. The vendor will likely want to take responsibility for making sure all of these preparatory steps are taken care of by providing a hassle-free installer.
Here is a list:
- The user’s CRM Online organization has an iframe somewhere to the vendor’s web page.
- The data model customizations are made, if the customer desires.
- Using RPS, the vendor can authenticate CRM Online users that browse to their page via the iframe.
- The vendor’s service can obtain a WLID for its service account.
This is where the new MIS feature called Enhanced Id (EID) comes into play. It has its own sub list of prerequisites:
Making the web service call to get the ticket can be tricky. The protocol is based on WS-TRUST, but it doesn’t follow the standard exactly. So we provide a class in the CRM SDK, WindowsLiveIdTicketAcquirer.cs to do it for you. You just need to provide the following:
|
- The vendor’s service account can access your org db via the SDK.
|
That means their service account needs to be a member of your org. That might set off some alarm bells. Yes, the vendor will need to obtain a certain level of trust from the administrator to obtain this. Thankfully, with CRM’s granular security model, you only need to yield to the vendor exactly the permissions necessary to get the job done. It’s true that more valuable services are likely to require more permissions, but on-premises cases such as ExactTarget and Sonoma Partners have proven that the tradeoff can be well worth it. As a vendor, having a strong privacy policy and a good reputation will get you most of the way there. Budget-conscious admins may still be hearing alarm bells. But thanks to another new feature, no, the service account won’t need to consume one of your precious licenses. If an account doesn’t need to use an interface other than the SDK, it can be flagged as a ‘non-interactive’ user, which won’t count against the license total because it can’t use a GUI to access CRM. |
- The vendor’s service account needs the correct privileges.
|
The ability to impersonate another user is secured in CRM Online through a new security role, Proxy. The service account needs to be assigned this role in order to successfully impersonate a user. The service account would also need basic access to the entities it needed to operate on. Read access to accounts, for example. During impersonation, the service account will only be able to perform actions that both it and the impersonated user have permissions to do (the intersection of the two privilege sets.) Also, the service account will assume the impersonated user’s security context, so accounts created by the impersonated user are treated as ‘owned’ accounts. Impersonation makes the most sense when the user is generating CRM SDK activity through the vendor’s web site. The vendor needs to use RPS to authenticate the user, and also make use of a new Discovery service request class, RetrieveCrmUserIdByExternalIdRequest, that allows translation of Windows Live unique ids (obtained via RPS) into CRM user ids (as long as you share an org with them.) It’s also worth mentioning that an action performed while impersonating a user is distinguishable from the same action performed by the user. There are new entity properties that will tell you if impersonation was involved or not and the identity of the proxy. |
Once everything is in place, a successful scenario would unfold like this:
After closing a big sale, the CRM user clicks over to the gifts tab, opening the vendor’s web site via an iframe. The user selects an impressive Mardi Gras themed flower arrangement, and confirms the purchase.
Meanwhile, the vendor has noted the org name from the incoming request, and authenticated the user with RPS. It obtains a WLID and CRM ticket for the service account, translates the CRM user’s WLID unique id into a CRM user id, and then enables impersonation on the CRM ticket by setting the token’s CallerId property to the user’s CRM user id.
The rest should be easy: read the contact info from CRM (you’re impersonating the user, so you can access their contacts), bill the customer, and add the gift and expense item records to CRM (as the user.) It’s a win for all parties involved!
Hopefully, the vendors who have put in a lot of effort to create innovative solutions targeting the on-premise CRM SDK will find it easy to enhance those offerings to make them available to the CRM Online community. That would represent a big boost in the options that our users have when putting together a killer CRM solution for their business.
Cheers,
Contributors
Matt Cooper
Stephanie Dart